6

I've noticed how in C++11, C++14 and onward, more and more Boost libraries are adopted/incorporated into the actual language standard (or into TS documents, which are likely to end up as part of the standard): Boost.optional, Boost.Any, Boost's threading library, smart pointers, etc. etc.

Are these libraries now maintained solely for usage with C++ code using an older version of the language standard, or do they have additional use? Specifically, are some of them considered alternative semantic variants to the choices of the C++ standards bodies?

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • Note, `optional` and `any` are in the Library Fundamentals TS, which is not part of the C++ standard, or even the working draft. Current implementations can place them into the `std::experimental::fundamentals_v1` and/or `std::experimental::fundamentals_v2` namespaces, but not into `std`. – Potatoswatter Jul 25 '15 at 08:27
  • 2
    Similar: http://stackoverflow.com/questions/8851670/relevant-boost-features-vs-c11 – sehe Jul 25 '15 at 09:20
  • This should probably be an FAQ on the Boost homepage. – Christian Hackl Jul 25 '15 at 09:51
  • @Potatoswatter: Edited question accordingly. – einpoklum Jul 25 '15 at 15:06

2 Answers2

3

One difference between the Boost and standard versions is that Boost may have deprecated functionality (design aspects that were decided after discussion and experience to be problematic, and so weren't added to the standard) or extensions to the standard (because Boost may have more flexibility than the standard and so has features that didn't make it into the standard).

For example, Boost.Thread's documentation lists several deprecations and extensions compared to the standard library.

Depending on your needs, these may be good reasons to go with Boost over the standard.

Josh Kelley
  • 56,064
  • 19
  • 146
  • 246
  • Do all Boost libraries which have been incorporated into the standard have EXTENSION and DEPRECATED markings? – einpoklum Jul 25 '15 at 20:28
  • @einpoklum - Boost.Thread is the only place where I've seen it - although threading is a much broader topic than smart pointers and optional, so changes (and the resulting extensions and deprecations) are more likely. – Josh Kelley Jul 26 '15 at 02:49
  • 1
    boost.thread is also a good example in that some of the functionality it grew since C++11 is now getting into the new Concurrency TS – Cubbi Jul 26 '15 at 02:51
2

I don't work for/on the Boost project, but yes, I expect that these features will for some foreseeable future be maintained, so that those who use an older standard for whatever reason (Common reasons are "the whole project is written in C++03" or "We have been using compiler X version A.B.C and we worry about testing with a new compiler version D.E.F"). The more "customers" you have for a project, the more important it becomes to update things gradually, and not change old behaviour unless absolutely necessary or remove old features.

It is of course still possible to use these features even in "modern C++" applications that use C++11 or C++14 (and sometimes they have subtly different semantics and/or syntax, so the change required to use the "modern C++" variant is more than "remove the #include of that boost"). Just because there is a new way to do something doesn't mean that all code-writers IMMEDIATELY change all their code to use that way... So using the "old" way will still happen and exist for quite some time after it has been adopted. And sometimes there are subtle differences that require further alterations to the source code, so more "thinking/typing" needed, which means the change is less likely to happen. If it's just a "replace boost::thread with std::thread" then it may happen quite quickly. If you also need to change some other code involved (arguments change order, the syntax/meaning of things subtly change, etc), then it's more of a "proper work to solve this", which usually means it gets lower priority in the development team (especialy if it's also "not giving much in the way of benefit")

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • ... but you're still implying that their main use becomes backwards-compatibility rather than an ongoing alternative to what's in the standard. – einpoklum Jul 25 '15 at 15:08
  • 1
    Well, if something is part of the standard, it's a) always available without using a secondary resource (e.g. extra downloads/installs for development) and b) maintained in the standard by the standard committee. The value of this is ranging from minor to a little more depending on how you see things, and of course people still use other external resources for a variety of reasons. But yes, at least in my view, using "standard" is better than using third party libraries, whether it is boost or some other library - on a scale where "worst is a poorly designed own library" is the lowest. – Mats Petersson Jul 25 '15 at 15:44
  • 2
    Well, Boost *is* a step above "other third-party libraries", exactly *because* it's a staging area for future standard candidates. So std > boost > other > own. I just wish more people in my department would accept that and stop swamping my desk with roll-your-own implementations for things that are *right there* in standard / boost libs. ;-) – DevSolar Aug 06 '15 at 10:48