C++ Feature Whitelist/Blacklist
Brendan Higgins
brendanhiggins at google.com
Wed Nov 2 11:53:44 AEDT 2016
Following up with what I think the whitelist/blacklist should be:
Blacklist:
* Variables of class type with static storage duration (including
constants),
plain old data types (POD) are allowed
- Main reason for this is that it is hard to keep track of when
these
variables get initialized
* Implicit conversion constructors and operators
- Makes code confusing and difficult to debug
* Multiple Inheritance (unless at most one of the parent classes is an
interface i.e. only has pure virtual methods)
- Detracts from readability
* Non-const-non-r-value references
- Use of const references and r-value references are encouraged
- For non-const-non-r-value-references use pointers
- Use where required or needed to maintain consistency with the STL
is
allowed
* Exceptions
- Functions have to explicitly opt out of exceptions with noexcept,
cleaner to assume no function throws exceptions
- No way to force exception handling (forcing handling of status
objects
is possible with the warn_unused_result attributes supported by
gcc
and clang).
- Exceptions are not typed
- Does not play nice with legacy code
- We are interested in porting existing code to OpenBMC most of
which is
not exception safe
Other considerations:
* Doing Work in Constructors
- Avoid virtual method calls in constructors, and avoid
initialization
that can fail if you can't signal an error.
- Don’t throw exceptions in constructors or destructors
- Generally, anything that can fail should be kept out of
constructors
- Maybe a separate Init function
Again, the above is by no means exhaustive; it only lists features which we
propose should be completely banned.
On the other hand, we do not think restrictions should be placed on using
virtual
functions.
Also, we do not feel strongly about stream operators, but would in general
object to using it as the primary grounds to not use a particular library,
as an
example.
(sorry about any html in the previous email)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161101/879628eb/attachment.html>
More information about the openbmc
mailing list