diff options
| author | Ed Tanous <ed.tanous@intel.com> | 2017-11-21 11:24:34 -0800 |
|---|---|---|
| committer | Brad Bishop <bradleyb@fuzziesquirrel.com> | 2017-11-29 16:55:08 +0000 |
| commit | 56d79455f15ef07be326e59fde4b47ca5866a30c (patch) | |
| tree | 44b71199b545cca406c94be36e4581010982cce8 | |
| parent | 3b3f95d284511c2c8dfed7029e89ff400618bf13 (diff) | |
| download | openbmc-docs-56d79455f15ef07be326e59fde4b47ca5866a30c.tar.gz openbmc-docs-56d79455f15ef07be326e59fde4b47ca5866a30c.zip | |
Update coding style to allow use of Boost
This follows the discussion on the mailing list titled "Use of Boost in
OpenBMC"
Change-Id: I156a17086e411287e7c7182cdb65ea620e280950
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
| -rw-r--r-- | cpp-style-and-conventions.md | 30 |
1 files changed, 17 insertions, 13 deletions
diff --git a/cpp-style-and-conventions.md b/cpp-style-and-conventions.md index 91e8119..08563a5 100644 --- a/cpp-style-and-conventions.md +++ b/cpp-style-and-conventions.md @@ -96,19 +96,23 @@ features or libraries. We do use exceptions as a basis for error handling within OpenBMC. -### 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. +### 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). ### iostream |

