As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm reading Boost array documentation and I see this line :
If you are using C++11, you should consider using std::array instead of boost::array
I was under the impression that Boost, for its major libs, was always preferable to standard lib because :
boost will never perform worse than the standard lib
boost may provide more features
boost is at last of equal quality than standard lib (people writing the C++ standard are active boost developpers/supervisors)
major boost features end up in the standard lib a few years later
So am I right to prefer boost over stdlib ?
If not / more complicated, which of my assumptions are to be corrected ?
I think you should use standard lib when available because... it's standard and comes with the compiler. Besides, if you use boost you need an annoying external dependency.
So, my advice is: use std when possible. If you're writing portable code, that must also be compiled with old compilers, you can consider to use your own namespace (e.g.: cxx0x) that embeds std or boost namespace according to the compiler you're using (this is called namespace alias):
#ifdef COMPILER_HAS_CXX0X
#include <memory>
namespace cxx0x = std;
#else
#include <boost/shared_ptr.hpp>
namespace cxx0x = boost;
#endif
...
cxx0x::shared_ptr<MyClass> = ...
Taken from the Boost people themselves:
Why should an organization use Boost?
In a word, Productivity. Use of
high-quality libraries like Boost
speeds initial development, results in
fewer bugs, reduces
reinvention-of-the-wheel, and cuts
long-term maintenance costs. And since
Boost libraries tend to become de
facto or de jure standards, many
programmers are already familiar with
them.
Ten of the Boost libraries are
included in the C++ Standard Library's
TR1, and so are slated for later full
standardization. More Boost libraries
are in the pipeline for TR2. Using
Boost libraries gives an organization
a head-start in adopting new
technologies.
Many organization already use programs
implemented with Boost, like Adobe
Acrobat Reader 7.0.
From my own experience I prefer to use boost for now. Maybe it's historical, but I found the STD attempts in TR1 that came with VC2008 had too many bugs, in spite of PJ Plauger's best efforts, he couldn't reproduce the quality of the peer-reviewed and checked code of boost that had gone through quite a bit of history.
Unless they can actually take the boost code and use it in STD, why would they reproduce it better? Of course sometimes they might, and really they should work together on it rather than against each other.
One thing I do now though is declare an alias namespace, usually called spns thus:
namespace spns = boost;
after which I can use spns::shared_ptr throughout my code (spns stands for "shared pointer namespace") and if we ever change to std later it will be easy to go to one place and edit just that line and the include.
When it comes to C++11, there are major changes to the Standard and boost's code is C++03. So now the tables are likely to turn for certain parts of the library. I reckon some of boost's fine libraries will become almost obsolete for C++11, e.g. nobody will use boost::lambda anymore, they will just use the new language syntax for a lambda.
So yes, when you move to C++11, it may be time to abandon parts of the boost library and use the new versions.
The trend that I have seen in open source software developed against C++11 is to move API-compatible (subset of) features from STD to boost - because boost is available for non-C++11-compatible compilers where the std features are (obviously) not.
Good example of this is mosh.
For API-compatible features, it's simply a matter of switching namespaces around. In fact, no reason not to make it a configuration option, if you can.
Sidebar: if you're linking against the latest version of non-header-only boost libraries, be forewarned that certain features are no longer available unless boost was compiled with -std=c++11. I ran into this recently with certain functions in the boost::filesystem API.
If something can be standard let it be standard.
If something cannot, use the solution more standard as possible (and BOOST is designed for that)
Many standard library feature are taken from boost, that continue to exist to support application that where deployed when those feature where not yet been standardized.
Using boost for standardized feature is in fact a "look backward". Sometime necessary (may be the standard library specific implementation does not include all what is required ... it is typical to see boost::thread instead of std::thread on windows because of a std implementation not yet been ported by some compilers) but I would not make it a rule.
Related
I am new user of the boost library. I find my self thinking more about adopting boost for a number of reasons. From what I can tell, it seems that the boost library is a sort of skunkworks sandbox where various C++ TR features for upcoming standardization are tried out before being adopted by the C++ committee - think boost::filesystem and boost::regex,
As an example, I was trying out some of the C++11 regex features in visual studio via the #include header - this worked great until I ported to a target power pc platform, which, at the time used CodeSourcery's GCC 4.7.3. Unfortunately, I realized that at run-time, that much of the regex implementation was incomplete or empty (even thought it compiled) - With a bit of homework, I should have realized this beforehand, however now that GCC 4.8.x is out, the implementation is part of the v3 standard C++ library so it is a different story now.
In an ideal world, the standard library should be like developing for Java - write once, deploy everywhere - but that is not a reality. I would eventually like to move to the standard library implementation rather than Boost's regex and filesystem implementations.
My question given the above regex history, is how should developers use boost, is it possible to do a simple search and replace of the boost headers and namespaces when the features are adopted by the standard library or are there more many things to consider. I would like to use pure C++11 code without dependency on 3rd party libraries.
The amount of work required to move from a Boost library to its C++11 conterpart depends on the degree of C++11 conformance of a particular Boost library. In the simplest case it can be a matter of including another set of headers and using another namespace.
In a more complicated case, Boost library may have some subtle incompliancy with C++11 (eg. in Boost.Thread V1 ~thread used to call detach()) - such things might "silently" break the code correctness, but they are easy to fix.
Finally, Boost library may implement funcionality that doesn't exist in C++11 (eg. boost::bind can be extended using get_pointer function). Apparantly, porting such a code to C++11 would be quite not trivial.
Let's begin with your statement
I would like to use pure C++11 code without dependency on 3rd party
libraries.
It is clear that this is not possible now. You will have to use 3rd party libraries for any non-trivial program.
Unfortunately, C++ with Boost is not a platform also. You need 3rd party libraries to do things available out of the box in languages like Java, C#, Python etc.
So, you have to select libraries according to your requirements: performance, supported platforms, multithreading etc.
Again, Boost shouldn't be your default choice. It is not that useful now as it was 10 years ago. Most of must have stuff went into C++ standard library already.
If you support existing C++ codebase, find the best C++ library for your needs (e.g. re2 for regex). If you start a new project, I would suggest using Qt as a platform.
A "simple" way to migrate usage may be to use preprocessor defines to define a "Using Boost" directive. By putting all boost code in an #if-#else and carefully writing the code to not break (or at least have expected results) for sections that do not have a C++11 equivalent. You can simply not provide a definition for "Using Boost" before at the beginning of your code and C++11 features would be used instead.
See this and this
One link points to an old stackoverflow question, the other to an interesting talk performed by Stephan Lavavej
The spate of questions regarding BOOST_FOREACH prompts me to ask users of the Boost library what (if anything) they are doing to prepare their code for portability to the proposed new C++ standard (aka C++0x). For example, do you write code like this if you use shared_ptr:
#ifdef CPPOX
#include <memory>
#else
#include "boost/shared_ptr.hpp"
#endif
There is also the namespace issue - in the future, shared_ptr will be part of the std, namespace - how do you deal with that?
I'm interested in these questions because I've decided to bite the bullet and start learning boost seriously, and I'd like to use best practices in my code.
Not exactly a flood of answers - does this mean it's a non-issue? Anyway, thanks to those that replied; I'm accepting jalfs answer because I like being advised to do nothing!
The simple answer is "do nothing". Boost is not going to remove the libraries that got adopted into 0x. So boost::shared_ptr will still exist. So you don't need to do anything to maintain portability.
Of course, once 0x is here, a lot of code can be simplified, cleaned up and optimized, but since it's not yet here, that work can't really begin. All you can do is make sure your code will still compile when 0x hits... and it should, just like that. Boost isn't going to delete half their libraries. (I'm not guessing. They've stated this on their mailing list before)
(and if you want to switch to the standard shared_ptr, I'd say it's probably easier to just do a simple search/replace when the time comes. Replace #include <boost/shared_ptr.hpp> with #include <memory>, and boost::shared_ptr with std::shared_ptr)
Or of course, you can just decide on the project that you're going to keep using Boost's shared_ptr. Just because it's been added to the standard library doesn't mean you have to use it, after all.
Nothing will need to be done because of namespaces. If you want to use the boost implementation you will still use the boost namesapce.
I don't think they would venture into breaking compatibility in such a big way with a previous version.
See my previous similar question here: what will happen with the overlapping portion of boost once C++0x becomes mainstream?
But of course if you do using namespace a lot in your code you may have some overlapping definitions. You'll have to go back to specifying the namespace explicitly on each use.
The best way to use shared parts between C++0x and Boost is to use the Boost.TR1, i.e; the implementation if the Technical Report already accepted. Boost.TR1 will use the implementation provided by the compiler when it is available, and the provided by Boost otherwise. This was the main goal of Boost.TR1
"The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. "
No we don't, as of yet, given the facts that:
support for C++0x is not yet upto the mark across the various platforms (we need) and
that it is yet to be declared a standard officially
But yes, we do use Boost as and when required (but of course, only after a release has gone through a sanitation phase do we use it) just like any other third party library that we use. Also, we use the source form on a as-needed basis.
There is however an effort towards more stringent adoption of the driving principles in product design phase (e.g. move-ctor etc).
There is definitely going to be some work when C++0x gets standardised; but that will also require us to move on to some of newer compilers (vc10?) and moving on to a new compiler is always a task in it's own.
You may actually always prefer using the Boost version for a long time. Especially if you need to compile on multiple platforms.
The Boost libraries are ported and tested on multiple platforms and behave the same there (most of the time.)
The first vendor implementations of the new C++ libraries may still contain minor bugs and performance differences just like it was such a mess when STL and the std namespace were added.
what will happen with the overlapping portion of boost once C++0x becomes mainstream?
Will boost still contain everything it used to, or will they adapt the library to update it with the new std:: stuff?
Will boost have both a normal c++ version and a c++0x version that they will maintain?
One would hope that Boost continues to support existing classes, for a couple of reasons.
First, there is a body of code that uses the overlapping features in Boost that needs to be supported, for some time.
Second, overlapping implementations allow me to select which one I'd prefer to use. There might be some difference between std::Frob and Boost::Frob that is important to my project, and having a choice is good.
In the long term, though, I would expect a migration toward the standard from both the application writers and the tools providers. That makes it a less risky choice to go with std::.
I am not affiliated with Boost and have no they idea what they will do but it seems like Boost will be left untouched.
There already has been released TR1 (VS 2008 feature pack) and Boost was left untouched. Since many users have not adopted Boost or TR1 yet, my prediction is that for at least next five years boost and c++0x libraries will exist in different namespaces and availaible for C++0x users as well as C++ users.
Namespaces make this somewhat of a non-issue for the Boost developers. There is no direct contention between the boost libraries and the standard libraries because they exist in separate namespaces. Therefore, changes to namespace std (for example the addition of std::tr1) have no direct impact on Boost.
Note however, that if you are importing both libraries (std and boost) into the global namespace, then you will have issues.
The following quote from the Boost TR1 documentation also sheds some light regarding Boost's implementation of TR1 components, suggesting that the corresponding Boost library will be maintained for the foreseeable future:
The TR1 library provides an
implementation of the C++ Technical
Report on Standard Library Extensions.
This library does not itself implement
the TR1 components, rather it's a thin
wrapper that will include your
standard library's TR1 implementation
(if it has one), otherwise it will
include the Boost Library equivalents,
and import them into namespace std::tr1.
Do you mean tr1?
Boost already supports tr1.
All the classes from boost that have been adopted into std::tr1 are available in this namespace from boost. See the following documentation.
http://www.boost.org/doc/libs/1_37_0/doc/html/boost_tr1.html
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
So, I've been reading through and it appears that the Boost libraries get used a lot in practice (not at my shop, though). Why is this? and what makes it so wonderful?
Boost is used so extensively because:
It is open-source and peer-reviewed.
It provides a wide range of platform agnostic functionality that STL missed.
It is a complement to STL rather than a replacement.
Many of Boost developers are on the C++ standard committee. In fact, many parts of Boost is considered to be included in the next C++ standard library.
It is documented nicely.
Its license allows inclusion in open-source and closed-source projects.
Its features are not usually dependent on each other so you can link only the parts you require. [Luc Hermitte's comment]
From the home page:
"...one of the most highly regarded and expertly designed C++ library projects in the world."
— Herb Sutter and Andrei Alexandrescu, C++ Coding Standards
"Item 55: Familiarize yourself with Boost."
— Scott Meyers, Effective C++, 3rd Ed.
"The obvious solution for most programmers is to use a library that provides an elegant and efficient platform independent to needed services. Examples are BOOST..."
— Bjarne Stroustrup, Abstraction, libraries, and efficiency in C++
So, it's a range of widely used and accepted libraries, but why would you need it?
If you need:
regex
function binding
lambda functions
unit tests
smart pointers
noncopyable, optional
serialization
generic dates
portable filesystem
circular buffers
config utils
generic image library
TR1
threads
uBLAS
and more when you code in C++, have a look at Boost.
Because they add many missing things to the standard library, so much so some of them are getting included in the standard.
Boost people are not lying:
Why should an organization use Boost?
In a word, Productivity. Use of
high-quality libraries like Boost
speeds initial development, results in
fewer bugs, reduces
reinvention-of-the-wheel, and cuts
long-term maintenance costs. And since
Boost libraries tend to become de
facto or de jure standards, many
programmers are already familiar with
them.
Ten of the Boost libraries are
included in the C++ Standard Library's
TR1, and so are slated for later full
standardization. More Boost libraries
are in the pipeline for TR2. Using
Boost libraries gives an organization
a head-start in adopting new
technologies.
Many organization already use programs
implemented with Boost, like Adobe
Acrobat Reader 7.0.
A few Boost classes are very useful (shared_ptr), but I think they went a bit nuts with traits and concepts in Boost. Compile times and huge binary sizes are completely insane with Boost, as is the case with any template-heavy code. There has to be a balance. I'm not sure if Boost has found it.
It adds libraries that allow for a more modern approach to C++ programming.
In my experience many C++ programmers are really the early 1990s C++ programmers, pretty much writing C++ classes, not a lot of use of generics. The more modern approach uses generics to compose software together in manner thats more like dynamic languages, yet you still get type checking / performance in the end. It is a little bit ugly to look at. But once you get over the syntax issues it really is quite nice. Boost gives you a lot of the tools you need to compose stuff easily. smart pointers, functions, lambdas, bindings, etc. Then there are boost libraries which exploit this newer way of writing C++ to provide things like networking, regex, etc etc...
if you are writing lots of for loops, or hand rolling function objects, or doing memory management, then you definitely should check boost out.
BOOST's a collection of libraries filling needs common to many C++ projects. Generally, they do prioritise correctness, reusability, portability, run-time performance, and space-efficiency over readability of BOOST implementation code, or sometimes compile times. They tend not to cover complete high-level functional requirements (e.g. application frameworks), and instead (thankfully) offer building blocks that can be more freely combined without dictating or dominating the application design.
The important reasons to consider using BOOST include:
most libraries are pretty well tested and designed: they generally get a reasonably sound review by some excellent programmers, compared to by people with home-brew solutions in the same problem space, and widely used enough to gather extensive real-world feedback
it's already written and your solution probably isn't
it's pretty portable (but that varies per library)
more people in the C++ community will have a head-start in helping you with your code
BOOST is often a proving ground for introduction to the C++ Standard, so you'll have less work to do in rewriting your code to be compatible with future Standards sans BOOST
due to the community demand, compiler vendors are more likely to test and react to issues of correctness with BOOST usage
familiarity with boost libraries will help you do similar work on other projects, possibly in other companies, where whatever code you might write now might not be available for reuse
The libraries are described in a line or two here: http://www.boost.org/doc/libs/.
Because the C++ standard library isn't all that complete.
Boost basically the synopsis of what the Standard will become, besides with all the peer review and usage that Boost gets you can be pretty sure your getting quite a good deal for your dependencies.
However most shops don't use Boost, because its an External Dependency. And in reality reducing External dependencies is very important as well.
Anything with Kevlin Henney's involvement should be taken note of.
Boost is to C++ sort of like .NET Framework is to C#, but maybe on a smaller scale.
I use the filesystem library quit a bit, and the boost::shared_ptr is pretty nifty. I hear it does other things too.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Since I have started using this site, I keep hearing about the Boost library. I am wondering what are some of the major benefits of the Boost library (hence why should I use it) and how portable is the Boost library?
Boost is organized by several members of the standard committee.
So it is a breeding ground for libraries that will be in the next standard.
It is an extension to the STL (it fills in the bits left out)
It is well documented.
It is well peer-reviewed.
It has high activity so bugs are found and fixed quickly.
It is platform neutral and works everywhere.
It is free to use.
With tr1 coming up soon it is nice to know that boost already has a lot of the ground covered. A lot of the libraries in tr1 are basically adapted directly from boost originals and thus have been tried and tested. The difference is that they have been moved into the std::tr1 namespace (rather than boost).
All that you need to do is add the following to your compilers default include search path:
<boost-install-path>/boost/tr1/tr1
Then when you include the standard headers boost will automatically import all the required stuff into the namespace std::tr1
For Example:
To use std::tr1::share_ptr you just need to include <memory>. This will give you all the smart pointers with one file.
You can simply read the Boost Background Information page to get a quick overview of why you should use Boost and what you can use it for. Worth the few minutes it takes.
99% portable.
I would say that it has quite a few libraries that are really useful once you discover a need that is solved by boost. Either you code it yourself or you use a very solid library.
Having off the shelve source for stuff like Multi-Index, Lambda, Program Options, RegEx, SmartPtr and Tuple is amazing...
The best thing is to spend some time going through the documentation for the different libraries and evaluating whether it could be of any use to you.
Worthy!!
Boost is great, but just playing Devil's Advocate here are some reasons why you may not want to use Boost:
Does sometimes fails to compile/work properly on old compilers.
It often increases compile times more than less template-heavy approaches.
Some Boost code may not do what you think that it does. Read the documentation!
Template abuse can lead to unreadable error messages.
Template abuse can lead to code hard to step through in the debugger.
It is bleeding edge C++. The next version of Boost may no longer compile on your current (older) compiler.
All of this does not mean that you should not have a look at the Boost code and get some ideas yourself even if you do not use Boost as it is.
You get a lot of the things that are coming in C++0x. But aside from that generality, some of the better specifics are a simple regex library, a casting library for casting from strings to ints (Lexical cast):
int iResult = 0;
try
{
iResult = lexical_cast<int>("4");
}
catch(bad_lexical_cast &)
{
cout << "Unable to cast string to int";
}
A date/time library, among others...
using namespace boost::gregorian;
date weekstart(2002,Feb,1);
date thursday_next = next_weekday(weekstart, Thursday); // following Thursday
There's also a Python interface (Boost Python), a lexer/parser DSL (Boost Spirit):
// A grammar in C++ for equations
group = '(' >> expression >> ')';
factor = integer | group;
term = factor >> *(('*' >> factor) | ('/' >> factor));
expression = term >> *(('+' >> term) | ('-' >> term));
and that's just scratching the surface...
Boost is a collection of C++ libraries. 10 of which are being included in tr1 of C++0x.
You can get started with boost here.
Boost is a collection of high quality peer reviewed C++ libraries that place emphasis on portability and correctness. It acts as the defacto proving grounds for new additions to the language and the standard library. Check out their website for more details.
Boost's advantages:
It's widely available, will port to any modern C++ compiler or about any platform.
The functions are platform independant, you don't have to learn a new thread design for each new framework.
It encapsulates a lot of platfom specific functions, like filesystems in a standard way.
It's what C++ should have shipped with! A lot of Java's popularity was that is shipped with a standard library to do prety much everything you wanted. C++ unfortunately only inherited the limited C/Unix standard functions.
shared_ptr and weak_ptr, especially in multithreaded code, are alone worth installing boost. BOOST_STATIC_ASSERT is also pretty cool for doing compile-time logic checking.
The fact that a lot of the classes and utilities in boost are in headers, meaning you can get a lot of functionality without having to compile anything at all, is also a plus. Portability usually isn't a problem, unless you use an extremely old compiler. I once tried to get MPL to work with VC6 and it printed out 40,000 warnings/internal errors before exploding completely. But in general most of the library should work regardless of your platform or compiler vendor.
Take into consideration the fact that quite a few things from Boost are already in TR1, and will most likely be in the next revision of the C++ standard library. That's a pretty big endorsement.
Boost is a very extensive library of (usually) generic constructs that can help in almost any application. This can be shown by the fact that a lot of boost components have been included in the C++ 0x specifications.
It is also portable across at least the major platforms, and should be portable to almost anything with a mostly standards compliant C++ compiler.
The only warning is that there can be a lot of mingled dependencies between boost libraries, making it harder to pick out just a specific component to distribute (other than the entire boost library).
All of the above, plus it encourages a lot of modern, best-practice C++ techniques. It tends to improve the quality of your code.
Also note most of boost is templates so does not require building
(just include the correct header files).
The few parts that do require building are optional:
These can each be built independently thus preventing unnecessary bloat for unneeded code.