Use of Boost in OpenBMC

[Tanous, Ed]

All,

I'd like to start a discussion around the thoughts about the inclusion of Boost headers.  I've heard before that it's a controversial subject.

For record, here's what the style guide currently says:

Boost, QT, etc.

If you give a mouse a cookie...
While, in general, we appreciate reuse over rewriting, we are not using large general-purpose libraries such as Boost. Due to 'Code should be performant: code size' we do not want to utilize the entirety of Boost. If approval is given for a single part of a large general-purpose library it becomes much more difficult to disapprove of another part of the library. Before long, we may have effectively approved of the entire library.

We do look for single feature libraries that can be used in place of our own implementations.

I'd like to start a discussion around challenging a core tenant of this statement, that approval of one part of the library makes it difficult to disapprove other parts.  I would argue that the overhead of making a library available, while still rejecting improper use that effects the project, is much lower than rewriting and debugging equivalent "new" components for openbmc.

I would like to update the coding style conventions with the below verbiage in regards to boost.

Boost

Use of boost is allowed, under the following circumstances:

1.       Use is done as a header-only library.  This allows unused functions and methods to be removed by the compiler at link time, and avoids adding large amounts of overhead and flash usage.

2.       Implementers should include the lowest level header required to solve the problem at hand.  This allows uses to be found and moved forward when new standards are available, as well as reduce compile times, and decrease the possibility of accidental use.  (ie, #include <boost/container/flat_map.hpp>  not #include <boost/container.hpp>)

3.       The module used should not have an equivalent in the std namespace that meets the same requirements for implementation or clarity:  For example, std::chrono should be preferred over boost::chrono.  std::array over boost::array.

4.       Use does not conflict with any of the core tenants of this coding standard (clarity, modern practices, or performance)


Some examples of libraries in boost that (I believe) would be useful for openbmc:
Boost containers (flat_map, flat_set, ect)
                Among other things, this module provides standards compliant containers backed by a sorted vector.  This allows a reduced memory footprint over using std::set or std::map, and in certain use cases can be more performant, or lower memory usage.

Boost asio
                This module provides C++ level networking, sockets, SSL, and asynchronous frameworks that are not available in C++ today.  It has been proposed as a Networking TS to the C++ standards committee.  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf  This use would likely align us with moving toward compliant standards in the future.

Boost string
                Implementations of common string operations not present in the standard library.  String join, split, case insensitive compare ect.


I'd like to see what other people opinions are on the matter, and see if we can reach a consensus.

Thanks,

-Ed


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171113/a708d272/attachment-0001.html>