Sign in to follow this  

Boost Libraries

This topic is 3589 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

It's not so much a question of "Is boost worth using in C++?" so much as it is a question of "Is C++ worth using without boost?", in my opinion, to which my answer is "No, it is not."

So yes, it's definitely worth learning boost if you're going to use C++. Not all at once or anything, but one of the nice things is it's a collection of separate libraries which are easy to learn and apply individually. You could start with just the smart pointer library, for example. And when you want to do something and think, "Hey, doesn't Boost have something for this?", then you can get ahold of another part of the library.

Heck, there's still a few libraries in the boost collection that even I haven't learned. But it's nice to know they're there should I have a need for them in the future.

Share this post


Link to post
Share on other sites
Just to reinforce what's already been said...

If you're going to bother with C++, you might as well use (at least some of the libraries from) Boost.

If you don't use Boost, you're either going to:

a) write brittle, unsafe, and/or unidiomatic code, or
b) end up implementing functionality already offered by Boost yourself.

Furthermore, it pretty much goes without saying that it'll take you less time to learn to use the libraries in question than it will to write and debug the equivalent code yourself (most of the libraries are really quite easy to use).

Disclaimer: there may be cases where it really is preferable (or perhaps even necessary) to roll your own solution rather than using a specific Boost library, but these cases will be the exception and not the rule.

Share this post


Link to post
Share on other sites
Quote:
is it really worth the time of learning


Unlike MSCP, which costs $X and grants you a Y% raise, boost doesn't come with certification (or perhaps it even does). So the usual financial benefit isn't there.

What to learn then? Stuff that gives you immediate, tangible benefit? Certifications are fine, but they only go so far (in honesty, they go really far).

So at pragmatic level, it comes down to this: What is your involvement in software development? A career? Hobby as a student? It-pays-the-bills(tm)? Passion? Way to get rich?

There are many situations where learning a lot of domain-specific subjects may be counter-productive to your ultimate goal. A naive stereotypical example: if you're aiming to elbow yourself into management, then time spent on office politics, management courses and MBA degree will be much better spent.

But there's something that's missing from your question, namely your past C++ experience. Anyone who's worked with C++ seriously (dead-lines, real-world environments, etc.) and has looked at boost said: "Now this is something that solves my problems". There's another category of people who looked at boost and mumbled "template-based intellectual masturbation". This second group has semi-warranted reasons for their claims and mustn't be discarded by default.

And then sometimes, ignorance is bliss. Getting stuck on a VC 6 project, dealing with MFC legacy, it's better to not know the alternatives. It makes it easier to feel good about that code.

"Worth" is very relative. So rather than relying on opinion of people who have absolutely no idea about Boost's worth to you, take a look at it. Three things will happen:
- Wow, just what I always needed
- Ouch, way over my head
- Bleh, too messy, I'm not touching that

Always use the tools that you find helpful. Learn to evaluate them yourself. Following the hype, even in case of boost, is likely to leave you disappointed.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
"Worth" is very relative. So rather than relying on opinion of people who have absolutely no idea about Boost's worth to you, take a look at it. Three things will happen:
- Wow, just what I always needed
- Ouch, way over my head
- Bleh, too messy, I'm not touching that

Some really good points. But just to reinforce what was said before, one of the nice things about Boost is that it's a collection of separate (and each one usually relatively small and easy to use) libraries. So when you take a look at Boost, remember that you don't have to understand or use *all* of it.
Some parts of Boost are extremely straightforward to use, and saves you a lot of bother, while others require you to *really* know the ins and outs of C++, and be willing to spend quite a bit of time with the documentation.
So yes, as Antheus said, take a look at Boost, and find out if it's worth using in *your* case. But don't look at Boost as a whole, because that's just scary, pick out the individual libraries you're interested in.

(In general, if you're not tied up with an ancient VC6 codebase, and if you care about programming, MaulingMonkey's answer probably applies. Boost is more or less the standard library C++ should have had)

Share this post


Link to post
Share on other sites
What boost class(es) should i learn? from what i hear i should learn the share_ptr and related (auto_ptr? weak? i dont know what else).

and i also heard nothing else about boost :|. just that the share ptrs are good...

Share this post


Link to post
Share on other sites
Go to the boost website. Go over the list of libraries in the documentation section. For each library: if it sounds like something you can use in your current project, read more about it. If it still sounds useful, learn it.

Share this post


Link to post
Share on other sites
I really wonder how many people recommending Boost here are using it in successful commercial products. The problem with Boost is that it offers many cool things that sound useful, but are painful to use in practice or simply buggy to the point of unusability. Additionally, most of the larger pieces of code in Boost have insanely deep dependencies on the rest of Boost, so you end up dragging in masses and masses of header files just to get some innocuous sounding functionality and your compile time goes down the toilet.

Share this post


Link to post
Share on other sites
I have to agree with most of what was said here. Basically these things are important:
Use what increases your productivity, your code readability, code flexibility and reusability.

Personally I am of the oppinion that using libraries as rarely as possible, i.e. only when theres a significant increase in productivity, is beneficial since it makes the code readable for a wider variety of people, it enforces strict OO design patterns and optimization and it makes it more compatible (let's say you wanted to translate your code to C or another language for instance).

Why things are more readable is simply because some people are not familiar with boost. I mentioned OO design because after having a quick look at shared_ptr it seems that using these could easily make one lazy, having pointers come up in various classes that should be confinded from an organizational perspective to one class. Having simple pointers in a class and having this class make sure the memory is released is a good thing when using C++ in my oppinion. Offcourse using shared_ptr is just as good or perhaps better (my boost experience is limited) if you have a good programming style. In terms of optimization I'm not talking about the libraries algorithms because obviously you are not going to top those as a one man programmer. I do, however, fear that overuse of such powerful classes may make developers use complex datastructures for the simplest things. For instance using a full blown hash map module when all you need is a linked list that will be emptied once the same way a stack would. Or using something complex just to store a few strings...

When using C++ I tend to assume that a bit of lower level optimization is in order and many times C++ projects tend to aim at having a solid personal code base that is highly independent since otherwise I would be using java or C# which have faster productivity most of the time and they have all the complex data structures built in. Boost is a dependency one can live with though primarily since it is used widely commercially as far as I know.

In the end it all comes down to what project you are working on, some are more low level others require more high level tools. And offcourse personal preference matters as well.
I apologize for going somewhat off topic. In the end my advice is if you have the time have a good look at boost and use whatever you see fit.

-CProgrammer

Share this post


Link to post
Share on other sites
Quote:
Original post by truthsayer
I really wonder how many people recommending Boost here are using it in successful commercial products. The problem with Boost is that it offers many cool things that sound useful, but are painful to use in practice or simply buggy to the point of unusability. Additionally, most of the larger pieces of code in Boost have insanely deep dependencies on the rest of Boost, so you end up dragging in masses and masses of header files just to get some innocuous sounding functionality and your compile time goes down the toilet.
Both lengthy compile times and poor run-time performance can (sometimes) be an issue with (some of) the Boost libraries.

Could you provide some examples though of Boost libraries that are a) buggy, and/or b) painful to use?

Also, remember that there are many libraries in Boost. Occasionally bugs will pop up (I recently ran into one in the Serialization library, as a matter of fact). However, these bugs tend to be corner cases found in the more complex (and somewhat less commonly used) Boost libraries.

The oft-recommended Boost smart pointer classes, for example, are both easy to use and (I would wager) more or less bug-free. You could use nothing from Boost but these classes and still benefit, so the fact that library X has a bug (e.g. Serialization) or library Y is less than straightforward to use (e.g. Spirit) isn't particularly relevant.

Share this post


Link to post
Share on other sites
I consider myself an avid Boost user and I wouldn't want to work without it anymore. shared_ptr is probably the most quoted Boost library here, but I actually started by using Spirit, since I was fed up with lex/yacc woes. Format, thread, serialization, variant, function, bind, date_time, filesystem, graph: all top-notch libraries with very useful functionality I don't want to spend any of my precious time on trying to duplicate.

Currently I'm using almost all of them in some form or fashion in professional software development. Not all of them are easily understood at first, but as your insight into the language grows, so will your appreciation of the more complex boost libraries.

Share this post


Link to post
Share on other sites
Quote:
Both lengthy compile times and poor run-time performance can (sometimes) be an issue with (some of) the Boost libraries.
True that. This is a shame, as it can render libraries which would otherwise be absolutely great quite unattractive (boost::thread, anyone?).

Quote:
Original post by jykexamples though of Boost libraries that are a) buggy
Here's one example I recently bumbed into. Being in need of an atomic counter, I was foolish enough to think "hey, I bet there's one in Boost you can just use". So, I ended up wondering why my code wouldn't work for heaven's sake, it just had to work, but it failed unpredictably.
It turned out that when you read an atomic counter, it doesn't just read the value of that volatile, but performs a __exchange_and_add(&value_, 0). This isn't only unnecessary, but it also breaks your program because it secretly alters the counter's value (the documentation says "returns the value of a", which is what you'd expect, too).

Having said that, I use a few of the smaller Boost classes which have little dependencies every day to full satisfaction. In particular, the pointer classes indeed are a must-have for everyone.

Share this post


Link to post
Share on other sites
Quote:
Original post by samoth
Here's one example I recently bumbed into. Being in need of an atomic counter, I was foolish enough to think "hey, I bet there's one in Boost you can just use". So, I ended up wondering why my code wouldn't work for heaven's sake, it just had to work, but it failed unpredictably.


You mean the completely undocumented non-public atomic_count class in the detail namespace and directory? Did you ever consider that things in the detail directory might be there because users weren't supposed to use them directly? Misusing the library and then claiming that it's a bug in the library is not a particularly intelligent claim.

Share this post


Link to post
Share on other sites
I, too, consider myself an avid Boost user.

Quote:
Original post by samoth
Quote:
Both lengthy compile times and poor run-time performance can (sometimes) be an issue with (some of) the Boost libraries.
True that. This is a shame, as it can render libraries which would otherwise be absolutely great quite unattractive (boost::thread, anyone?).


I'm curious what performance issues you've noticed in Boost.Thread? I can't say I've noticed any noticeable performance degredation using Boost.Thread, although I have to say that their thread class could be better; it's very minimal. The rest of the stuff in Boost.Thread is great, IMHO.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare I'm curious what performance issues you've noticed in Boost.Thread?
None, and that's the point. boost::thread is just cool and awesome. It contains everything you need, it works, and it's cross-platform. It's what everyone should be using.
But it's not trivial to use it standalone, and it adds significant compile time, which makes it unattractive, and that's a shame because it's really good.

Quote:
Original post by SiCrane Did you ever consider that things in the detail directory might be there because users weren't supposed to use them directly? [...] not a particularly intelligent claim.
Thank you for setting me right once again (twice in a week already) in your special charming way.
I considered that when a class header has comments that document operator long as "returns the value of a" then it does exactly that, regardless of whether the header is in the detail directory or not. I see that this is a stupid claim now.

Forgive me for neither being intelligent nor having divination powers. One should of course foresee that "returns" means "returns and alters" and that cast operators regularly change an object's internal state.
Of course it is also an entirely stupid assumption that anything in the detail directory could possibly work in a normal way or the way it's documented in the class header. My fault.


Either way, I've not been saying (and I am not saying) that Boost is overly buggy or anything. But like most software, it isn't a panacea, it isn't free (in terms of compile time and code size), and it may contain quirks and bugs that can bite you painfully, if you're unaware.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
I, too, consider myself an avid Boost user.


I'm curious what performance issues you've noticed in Boost.Thread?


Thread is fine. It creates a thread. Then runs it. Then joins it. That's it.

The perceived problems come from weak synchronization primitives compared to other libraries. The reasons for this choice however are justified.

Part of the "problem" comes from the fact that C/C++ crowds are not thread happy (unlike, say, Java). And when it comes to portable native thread wrapper, boost is just fine.

There's some performance issues. conditional_lock, for example, is extremely slow under Windows before Vista due to lack of proper OS support (at least I seem to recall being related to that). It also lacks the more common primitives, such as semaphores.

But that's a matter of taste. Boost libraries do only what they can do "perfectly". Many of the libraries deliberately don't support certain features since they aren't needed.

And despite very verbose design and implementation, boost is quite ascetic and straight-forward. Each class/library does exactly what it's supposed to and not a single thing more.

Unfortunately, there's some code/role/functionality duplication between projects, and some libraries do suffer from performance problems (boost::function allocates functors on heap, boost::signal is considerably slower than comparable frameworks, boost::any performs redundant allocation on copy).

But as always, if that's a problem, there's other libraries. This is greatest benefit of the design - take what you need.

Share this post


Link to post
Share on other sites
Quote:
Original post by samoth
Of course it is also an entirely stupid assumption that anything in the detail directory could possibly work in a normal way or the way it's documented in the class header. My fault.

No, it's an entirely stupid assumption that anything in the detail directory is intended for anything but the library implementation to use; that's why it's in a detail directory. The header documentation may be completely correct if used by the library. And if you don't want to be perceived as saying that your incorrect use of an undocumented feature is an example of a buggy library; then don't quote a post that says "examples though of Boost libraries that are a) buggy" before describing your expedition into undefined behavior as if it was an actual boost library rather than a misuse of a non-public library component.

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
It's not so much a question of "Is boost worth using in C++?" so much as it is a question of "Is C++ worth using without boost?", in my opinion, to which my answer is "No, it is not."


nifty [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
It's not so much a question of "Is boost worth using in C++?" so much as it is a question of "Is C++ worth using without boost?", in my opinion, to which my answer is "No, it is not."


QFE. For the last 6 months, I've been writing C# instead of C++ and I sometimes find myself wishing I could use boost features in C#.

If I had to go back to programming in C++, I could happily do so. If I had to go back to programming in C++ without boost, I doubt I'd accept the job.

And for the record, I've used shared_ptr, pointer containers, regex, format, concept_check, filesystem, function, bind (a lot!), test, thread and statechart all in production code in a professional capacity, plus I added a complete scripting system with boost.python (primarily) for testing purposes. Considering the huge amount of functionality those libraries provided I ran into very few problems, and the productivity boost (no pun intended [grin]) far outweighed any issues or performance problems.

Share this post


Link to post
Share on other sites

This topic is 3589 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this