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.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Very often here on SO I see notes about boost such as
If you are fine with using Boost...
or
If you can use Boost...
And I wonder, what's that all about? What should I be weary of? When can't I use boost? What are the reasons not to use boost? In my opinion boost is a great extension to STL; sometimes very heavyweight and clumsy, but great nevertheless.
I am not really asking for opinions about boost as such. I am rather looking for some concrete examples when should I think twice before using boost.
When I can't use boost? In my opinion boost is great extension to STL,
sometimes very heavyweight and clumsy, but great nevertheless.
Boost is not a library but a collection of largely independent libraries of individual quality. With this in mind, and also taking into account that I'm personally a big fan of most of Boost, here are some reasons I can think of for not using certain Boost libraries:
Some Boost libraries are redundant since C++11.
Some libraries are not widely used and thus require expert knowledge in your project which might be expensive to replace when an employee leaves the company.
Company guidelines which developers have to obey more for political than for technical reasons.
You have no guarantee that any Boost library will be continued to be maintained in the future. Standard C++ code written for some compiler today will very likely continue to work fine with a newer compiler by the same vendor 10 years from now, for simple commercial reasons. With Boost, you have to hope that enough competent people will have any interest in long-term maintenance.
No Boost library is documented as extensively, with so much material in countless books and on the internet, as the C++ standard library. Who will support you if you have some really exotic problem with a particular library? Surely with standard C++ your chances of finding people with the same problem (and existing solutions for the problem) are much higher.
Debugging some Boost code can be more difficult than debugging code that uses the standard library.
Because it's not an extension to the C++ Standard Library (nor to the STL, naturally).
It is a third-party distribution, that you must download and install, locally and (for some Boost libraries, if you dynamically link) on the target system. You must manage and document the dependency.
I shan't enumerate all the scenarios in which this is not feasible, but it should be self-evident that you cannot always use non-standard code. Not everybody is working on a platform on which you can simply write yum install boost-devel, write your code and move on. The world of computers goes far beyond commodity desktop PCs.
That being said, most arguments for avoiding Boost are incredibly weak, due to its extreme portability, and the fact that the majority of Boost libraries are header-only (which reduces the packaging overhead significantly).
Seems like a lot of fuzz for nothing
I don't think writing the phrase "if you can use Boost" can be honestly described as "a lot of [fuss]".
Maintenance mostly.
Once you add boost, you have to maintain it. Either get updates (and maintain any changes mandating changes in your code), or freeze the version and fix bugs yourself.
Both are expensive and backloaded costs. For a project with a lifespan measured in decades, such costs are highly important.
In addition to #LightnessRacesInOrbit's point, I'd say there are a few reasons:
Boost has a lot of code in .h and .hpp files, which you need to include in every translation unit (which uses the relevant parts of Boost), and those files are laden with complex and recursive macro use and smart - but again, complex - use of templates. The combination makes your compilation a w-h-o-l-e lot slower.
Boost isn't installed everywhere by default, so it's not always available to you just because C++ and the standard C++ library is.
(A new reason actually) A sizeable fraction of Boost functionality has made it into C++11 (more is in C++14, and still more in C++17). So, by now, there are alternatives in the standard library or even the language itself for part of what Boost offers.
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.
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 11 years ago.
For a long time being a Java programmer and only hearing boost mentioned I thought it was so favoured because the Standard C++ language doesn't have any mechanism for threading. However, I then stumbled on the fact that there are libraries one can use on linux for threading. Therefore I am a little puzzled why the boost libraries are so popular?
From the perspective of someone deciding which parts of boost to get "stuck in" and learn, could programmers who use it please explain why it is so popular and the most favoured parts from the point of view of recruiters (preferably financial development)?
To make this more Stackoverflow-friendly, what are the libraries/features which make boost what it is?
I thought it was so favoured because the Standard C++ language doesn't have any mechanism for threading. However, I then stumbled on the fact that there are libraries one can use on linux for threading.
That's odd reasoning. There is a lot more to Boost than threading. Plus, just because there's a Linux library for threading doesn't mean it will work on your Windows code; Boost.Thread is cross-platform.
Allow me to hit some of the high points of Boost:
Smart Pointers
C++11 now has most of these (and improvements on them using C++11 language features). But for the past 8+ years, this was where you came for a good shared_ptr implementation. Use of these things should be mandatory where possible.
They make life in C++ so much simpler.
Regex
Not my cup of tea, and another Boost library incorporated into C++11. But if you want to do regular expression searching of strings, it doesn't get much more standard than this.
Bind and Function
Yet another thing that was incorporated into C++11, but unless you have access to a C++11 compiler/library, Boost is your best bet for this. Being able to store any kind of "callable" object in an object is incredibly useful for callbacks. And being able to adapt "callable" objects to different sets of parameters is incredibly useful, particularly with algorithms.
Filesystem
C++ has standard library facilities for opening and closing files. But nothing for looking for them or dealing with filenames. Boost does, and in a very nice API to boot. It handles platform-specific encoding through a platform-neutral interface. It allows Unicode support across those platforms that have it, etc.
Range
You know how the standard algorithms take a begin and end iterator, but most of the time you really just want it to walk the whole container? Range is here for you. It defines iterator ranges (which containers are), and it provides algorithm variants that take range objects explicitly.
What's great about Range is that the range algorithms are lazily evaluated. So you can do functional-style composition of algorithms, which works efficiently. Many algorithms return a range (which is really a range placeholder); if you feed one range into another range, you can get powerful effects with simple composition.
Variant
AKA: a type-safe union. Once you put an object of type X into it, you cannot get anything but type X out of it. Period. This is a useful tool for doing some light runtime-polymorphism work without having to use a derived class.
These are just a few of the libraries in Boost.
Boost is in part, a staging arena for proposals for the standard template library. It has strong threads solutions. However, boost also provides a wide range of other things such as containers, expression parsers... It is famous because it is a central repository for C++ non-standard libraries.
These are the libraries/features which make boost what it is. Threading is not the only thing you want to do in an application... The most "favored" depends on what you are programming, all of the libraries are useful, otherwise it would be unlikely to have been included.
Boost is just a big non-standard library collection.
C++'s STL is getting better and better, yet it's not nearly as huge as Boost (and is not intended to).
Think of Boost as a collection of useful libraries (for various purposes from math thru parsers thru containers to metaprogramming, see the docs for the list) which is known to be of good quality and just happens to be packaged together.
"boost" is just a repository of high quality C++ libs. If you write a good C++ library useful for a lot of people and which meets boost quality standard, you can ask it to be added to boost.
It happened that influent C++ programmers who are working on the C++ standards are also writers of some boost libs. Some boost libs are now standard. That makes it a central place for the C++ community.
Concerning your question about threads, boost would offer portability over using a linux-only thread lib. The boost version works on windows, too.
As a Java program you're probably used to having classes available at your fingerprints for doing a wide variety of things, from threading to XML parsing to logging to regular expressions.
The C++ core language is sparse in this regard compared to most other languages. We've got containers and algorithms, but not a lot else. Boost fills some of the gap between C++ and other languages in terms of ready-made and test libraries that we can import and useo right away rather than spend time reinventing them.
In C++11, some of the best libraries in Boost (Regex, Unordered Cntainers, Smart Ptr to name a few) are becoming part of the language. That isn't a coincidence, it's a direct result of their popularity and maturity as part of Boost.
In terms of what is most attractive, I would say a cursory familiarity with every library would be most important. Be able to say "Yes I've used boost" and "Boost.Widget" would be a good fit for this problem. Most everything else is just API reference.
If I had to pick one: Boost.Asio has definitely changed the way I think about networking. (And it's use of shared_from_this() and Smart Ptr show me new ways to think about memory management. Sorry, I guess that's two.)
Many utilities of boost have been included as part of extended C++ TR1 currently.
Is the complete boost library going to be included once the standard is officially out ? In other words, do I need boost library, if I have complete standard conforming C++11 compiler ?
If not then any reason for that (Reliability cannot be an issue; as far as I know it's written by many people from standard committee) ?
Boost is huge, and of generally high but still varying quality. A lot of the APIs - even the techniques and functionality - are quite "experimental" in the sense that they're still regularly modified as real-world feedback comes in. By way of contrast, the Standard is expected to get it right and need minimal revision, especially when that breaks backwards compatibility.
The standard for review for Standard libraries is much higher than boost's, which is not to say that many boost libraries wouldn't meet the bar - just that many wouldn't too, and that the review process itself is time consuming. There are terrific programmers coordinating and contributing to boost, but they naturally focus their time on their own development interests and things they see as more relevant, so if something is a little specialised, doesn't appeal to their coding style, etc. it may not receive the same scrutiny. The Standard library needs to be scrutinised much more thoroughly as the consequences of change are so much more painful.
While portability is a factor in acceptance of a library into boost, it's not a hard and fast requirement, where-as compiler vendors are expected to make the Standard library run on all C++ compilers, so taking boost more or less as-is and expecting the functionality to be universal on Standard-compliant compiler vendors would put a huge workload on those vendors.
No, in fact very few parts of Boost are "included" in the C++0x revisions to the C++ Standard Library. The parts that are "included" are some of the most commonly used parts of Boost, though.
Really, "included" isn't correct anyway: there are many differences between the Boost libraries and the corresponding additions to the C++ Standard Library. Further, the Boost libraries continue to grow and evolve; the C++0x Standard Library is now finished.
No, Boost is not going to be included in its entirety in C++0x.
Parts of Boost will be, like boost::shared_ptr, Boost.Array, and a couple of other things. But most of Boost is not being included.
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.