Cppcoreguidelines: SL.3: Prefer the Boost libraries over other non-STL libraries

[richelbilderbeek]

Edit: Thanks to @nadiasvertex: added exceptions

SL.3: Prefer the Boost libraries over other non-STL libraries

Reason:

The Boost libraries are praised for being well-designed by, among others, Alexandrescu, Stroustrup, and Sutter. The Boost libraries have a history of being the pre-STL libraries, as some Boost libraries have made it into the STL. For example, the boost::shared_ptr became the std::shared_ptr.

So when the STL lacks what you need, look in the Boost libraries first.

Examples:

• Graphs: Boost.Graph
• Signal-slot: Boost.Signals2
• many more

Alternatives:

Exceptions:

• Not everything (e.g. 3D graphics) is in Boost
• Some Boost libraries may feel too over-engineered and have a too steep learning curve to suit your needs

Enforcement:

See alsos:

Notes:

Discussion:

[nadiasvertex]

The problem with Boost is that you often have to eat the whole pig just to
get a little bacon. Also, Boost has gotten a little lost in the weeds over
time.

Some large projects are actively trying to remove their boost dependency because maintaining it is such a hassle. I understand that Boost is actively working on some of these issues, but still.

While it is a good resource, I wouldn't go so far as to say that the entire community should prefer Boost by default.

On Sun, Jan 10, 2016 at 7:50 AM Richel Bilderbeek [email protected]
wrote:

SL.3: Prefer the Boost libraries over other non-STL libraries

_Reason_:

The Boost libraries are praised for being well-designed by, among others,
Alexandrescu, Stroustrup, and Sutter. The Boost libraries have a history of
being the pre-STL libraries, as some Boost libraries have made it into the
STL. For example, the boost::shared_ptr became the std::shared_ptr.

So when the STL lacks what you need, look in the Boost libraries first.

_Example_s:

• Graphs: Boost.Graph
• Signal-slot: Boost.Signals2
• many more

_Alternative_s:

_Exception_s:

_Enforcement_:

_See also_s:

_Note_s:

_Discussion_:

—
Reply to this email directly or view it on GitHub
https://github.com/isocpp/CppCoreGuidelines/issues/494.

[richelbilderbeek]

@nadiasvertex: Thanks, I agree and will edit the post as such

[jepessen]

I don't agree. These guidelines are referred to cpp language, not to external libraries usage. stl is handled hear because it's part of the standard, but boost, even if it's a widely used library, it's not part of the that. If a user wants to use another library, it's free to use it, I don't see a reason to prefer Boost over other libraries if they accomplish their work.

[Pazns]

It could serve as a crash test to let Boost being, or being not, used by people if it fits their needs.
Then, if it is widely used, it means it reflects a useful and important feature C++ should provide as a standard.

To recommend Boost over other non-STL libraries could mean Boost is in-practice a part of the standard, which may be a bad thing if it is not in-law.
Or, just make Boost part of STL already, at least it would be clearer then.

[CharlesBunders]

The reasons to prefer boost:

No other library is close in terms of widespread use.
No other library has as many parts of it that made their way in to the language.
No other library has as many members of the c++ standards committee working on it and providing guidance.
No other library follows the spirit of the STL as closely.
Code using a portion of boost that gets moved in the core language is less costly to migrate.

-Charles

On January 10, 2016 10:56:23 AM EST, Daniele Lupo [email protected] wrote:

I don't agree. These guidelines are referred to cpp language, not to
external libraries usage. stl is handled hear because it's part of the
standard, but boost, even if it's a widely used library, it's not part
of the that. If a user wants to use another library, it's free to use
it, I don't see a reason to prefer Boost over other libraries if they
accomplish their work.

---

Reply to this email directly or view it on GitHub:
https://github.com/isocpp/CppCoreGuidelines/issues/494#issuecomment-170361757

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[richelbilderbeek]

Thanks to @CharlesBunders, @nadiasvertex, @jepessen: added exceptions and additional reasons

SL.3: Prefer the Boost libraries over other non-STL libraries

Reason:

The Boost libraries:

• are the libraries with the most widespread use (except for the STL)
• closely follow the spirit of the STL
• have libraries that have made it into the STL. For example, the boost::shared_ptr became the std::shared_ptr.
• are easy to migrate when it gets moved in the core language
• has many members of the C++ standards committee working on it that provide guidance
• praised for being well-designed by, among others, Alexandrescu, Stroustrup, and Sutter

So when the STL lacks what you need, look in the Boost libraries first.

Examples:

• Graphs: Boost.Graph
• Signal-slot: Boost.Signals2
• many more

Alternatives:

Exceptions:

• Not everything (e.g. 3D graphics) is in Boost
• Some Boost libraries may feel too over-engineered and have a too steep learning curve to suit your needs
• You work on code that already uses other libraries

Enforcement:

See alsos:

Notes:

Discussion:

[nadiasvertex]

@richelbilderbeek I think it should also be fair to mention that the quality of boost components varies. It is true that many parts of boost are very high quality, whereas others are just there. This is the same kind of problem Python had in the beginning. Guido just accepted most contributions to the standard library, but eventually it had to be more actively curated.

In many ways boost is a proving ground. Sometimes that leads to good things, and sometimes it leads to less good things. While it is nice that members of the standards committee provide guidance, they are primarily domain experts in C++. While they might be able to give good guidance about how something should look from a C++ perspective, that doesn't mean that they know anything about the problem domain being addressed.

Choosing the right library is a balance between good C++ and a good solution for the problem at hand. It is somewhat dangerous to assume that a boost library has been peer-reviewed by people who understand the problem being solved simply because it is part of boost.

It should be emphasized that you should look at the costs and benefits of various implementations before making a choice. In other words, caveat emptor.

[cbsmith]

Suggesting that using Boost libraries ought to be preferred is still a good
rule of thumb.

On Sun, Jan 10, 2016 at 11:14 AM, Christopher Nelson <
[email protected]> wrote:

@richelbilderbeek https://github.com/richelbilderbeek I think it should
also be fair to mention that the quality of boost components varies. It is
true that many parts of boost are very high quality, whereas others are
just there. This is the same kind of problem Python had in the beginning.
Guido just accepted most contributions to the standard library, but
eventually it had to be more actively curated.

In many ways boost is a proving ground. Sometimes that leads to good
things, and sometimes it leads to less good things. While it is nice that
members of the standards committee provide guidance, they are primarily
domain experts in C++. While they might be able to give good guidance about
how something should look from a C++ perspective, that doesn't mean that
they know anything about the problem domain being addressed.

Choosing the right library is a balance between good C++ and a good
solution for the problem at hand. It is somewhat dangerous to simply assume
that a boost library has been peer-reviewed by people who understand the
problem being solved simply because it is part of boost.

It should be emphasized that you should look at the costs and benefits of
various implementations before making a choice. In other words, caveat
emptor.

—
Reply to this email directly or view it on GitHub
https://github.com/isocpp/CppCoreGuidelines/issues/494#issuecomment-170382851
.

Chris

[NicolBolas]

I don't think this is an appropriate thing for the core guidelines to recommend. Whatever your feelings are towards Boost, these guidelines should not be used for recommending libraries of any kind. It recommends using standard library tools because those tools _exist_ and are always present. The guidelines library is there purely for _safety_ reasons: span over naked array pointers, ensures for precondition checking in lieu of contracts, etc.

But ultimately, the guidelines should not be trying to bless any particular library.

[SimonTemplate]

IMHO Boost is slightly out of touch with c++ latest idéas, as c++11/14 has caused a new generation of libraries being developed. Boost might no longer be the prefered second library, we are gradually finding more attractive alternatives, not the least here on GitHub.

[hpesoj]

While I do like to use Boost wherever possible, as it follows the style of the STL, there is nothing that makes the Boost libraries inherently better than other libraries. Following this advice may result in the use of a less than ideal library, so I don't think this is a good fit for the guidelines.

[cbsmith]

A rule of thumb doesn't trump all other rational thought. It's there for
when all other rational thought doesn't provide a clear signal.

For all is failings, Boost has been where the C++ community has come
together to build solutions. I don't even understand the comment about
C++11/14 because much of what is in those newer updates was built on Boost.
That's seems reason enough for ties to go to Boost.

All else being equal, saying stdlib > Boost > others doesn't strike me as a
terribly controversial practice.
On Jan 12, 2016 6:36 PM, "Joseph Thomson" [email protected] wrote:

While I do like to use Boost wherever possible, as it follows the style of
the STL, there is nothing that makes the Boost libraries inherently better
than other libraries. Following this advice may result in the use of a less
than ideal library, so I don't think this is a good fit for the guidelines.

—
Reply to this email directly or view it on GitHub
https://github.com/isocpp/CppCoreGuidelines/issues/494#issuecomment-171138886
.

[hpesoj]

There are many libraries out there that I would consider as good as, or even better than, the Boost alternatives. Why should I still prefer to use Boost? This guideline doesn't make any sense. It's one thing recommending Boost as a good source of peer-reviewed, well tested and designed libraries, but it's another thing altogether to recommend using Boost libraries _instead_ of other 3rd party libraries.

[NicolBolas]

IMHO Boost is slightly out of touch with c++ latest idéas, as c++11/14 has caused a new generation of libraries being developed. Boost might no longer be the prefered second library, we are gradually finding more attractive alternatives, not the least here on GitHub.

Really? I haven't seen any one project that is as comprehensively useful, as a box of utility tools, as Boost. Oh sure, if you pit Boost against the sum total of C++ projects on GitHub (that isn't already in Boost), maybe. But I think it's unreasonable to say that Boost is "out of touch" with C++, just because it doesn't use every feature of modern C++ (because backwards compatibility is actually important to them).

And _nothing_ beats the convenience of having such a wide variety of tools bundled into a single system. The nice thing about having them all together is that, once you're using one tool, there is zero cost to using another. If I need a variant and I use Boosts, then I get 20 other things I could use for the cost of one dependency. Whereas if I download a variant type from GitHub, the cost of adding an equivalent to property_tree or whatever is the same as the cost of any library: yet another dependency and yet another build system.

Not to mention testing. God only knows how well some random code off GitHub has been tested. While Boost requires a comprehensive set of tests for its projects. Plus, Boost is widely used, so its libraries tend to be field tested too. Random code off GitHub is less likely to be so well tested.

That said, the core guidelines is not the place to start suggesting libraries to use.

[Pazns]

Not to mention testing. God only knows how well some random code off GitHub has been tested. While Boost requires a comprehensive set of tests for its projects. Plus, Boost is widely used, so its libraries tend to be field tested too. Random code off GitHub is less likely to be so well tested.

That said, the core guidelines is not the place to start suggesting libraries to use.

I think this is a pretty good summary on the subject.
+1.

[cubbimew]

If the consensus is that these guidelines won't recommend libraries (I agree, too), Appendix A should be dropped.

[AndrewPardoe]

There's a lot of stuff in Boost: much of it is fantastic, but some of it is experimental or in development. We'll echo the analogy above of not wanting to "eat the whole pig".

We wholeheartedly recommend using the parts of Boost that your project needs but not as an official recommendation in the Guidelines. We don't currently have the bandwidth to vet and recommend popular libraries.