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