Use of Boost in OpenBMC

vishwa vishwa at linux.vnet.ibm.com
Wed Nov 15 23:33:02 AEDT 2017


I like the proposal of using Boost when it makes more sense.

As an example, In one of the recent code development, I was looking for 
string tokenizer support and could not see that in C++ and Boost had a 
good support of that. I ended up using strtok_r for that development.

!! Vishwa !!

On 11/14/2017 05:49 AM, Brad Bishop wrote:
>> On Nov 13, 2017, at 3:36 PM, Tanous, Ed <ed.tanous at intel.com> wrote:
>>
>> 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
>
> This has my support.  I think (hope?) we can rely on a rigorous peer review process to flush out and raise awareness of any questionable usage.
>
> Would it make sense to have another bullet point documented somewhere to this effect?
>
> "If you are considering a boost component, it is suggested you outline your intended usage publicly (the mailing list) to avoid wasted effort if the community does not feel the specific usage is appropriate."
>
> -brad
>



More information about the openbmc mailing list