[quote name='swiftcoder' timestamp='1328038928' post='4908129']
I don't mean to be rude here, but in all honesty you can hardly be considered to an objective source on this topic.

Feel free to dispute the results if you like. To the best of my knowledge the results are accurate.
[/quote]

<derail>
Why do your comparison programs return 1 from main? And why are they using C libraries (rather than the C++ versions (i.e. cstdlib and ctime))?

Additionally, you're comparisons are flawed. You should always have the program running for at least a full second before starting any timing measurements (this is to allow things to settle down and system start-up overheads to not interfere as much with the timing). You also don't provide hard numbers from the results, and I don't trust any timings that take less than a second (because it's so easy for the system to introduce a little slowdown here and there, adding noise to your timing results).

I'm not saying yours isn't faster or any one library is better than another; I'm just saying I question your benchmark programs, and from the code in the benchmark programs I question the library as a whole.
</derail>

I'll post something on-topic here: Boost is actually a nice asset. Of course it's not a panacea, but it does have various solutions for very common problems. Yes, in-house solutions may have already been developed for some of these problems, but that's not true for everyone. We use it at my work (in addition to several other libraries).

But I don't make games at work. If we were making games, I probably wouldn't get to use Boost (as others have said, it's template/macro magic is pretty heavy, and compilers for some gaming platforms might not be able to handle it). In addition, Boost does have bloated parts, true. But it's also a collection of libraries, so it's nice that you can take what's convenient to you and leave the rest. If there isn't something convenient to you, then you're free to use something else.

I think some of the "developers hate boost" mentality you're seeing stems from programmers who don't know what they're saying (kunos is a good example of this), who say things that make programmers around them shudder. I mean really, "exceptions are for pussies" (even if you were just joking) and saying that manual memory management is way easier than some kind of smart pointer (because it's harder to type shared_ptr<type> than delete)? (I'm not saying you HAVE to use smart pointers over manual memory management; I'm saying that your argument is silly; C++ is not necessarily a pretty language, and making eye candy your goal is the wrong approach (nor am I saying your code should be ugly... it's just... your goal should be to produce a quality, bug-free application that accomplishes the necessary tasks)).

[edit]

I sound really cynical/negative/condescending in this post. I apologize for that. I was just trying to write my impressions and that's how it came out; unfortunately it didn't come out more elegantly. It's past my bedtime though so I'm not going to stay up later to revise it.

In particular, it's one of the very few solutions that works well with heavily templated code bases.

I won't argue with that.
[/quote]
I would ask the question of why is your code base so heavily templated as the can add additional problems.

I would ask the question of why is your code base so heavily templated as the can add additional problems.

Because almost the entirety of my code-base is written in a modern C++ style - i.e. functional programming and static duck typing via templates.

And I realise I may be a little pedantic on this point, but this is how C++ is meant to be written. If you want to use only OOP, go use a language that is designed for it (i.e. Objective-C).

[quote name='Cornstalks' timestamp='1328080261' post='4908299']
<derail>
Why do your comparison programs return 1 from main? And why are they using C libraries (rather than the C++ versions (i.e. cstdlib and ctime))?

OK, I'm going to use those headers, but haven't rerun the tests yet.
[/quote]
I didn't ask that question due to performance reasons, I asked it due to design and programming reasons. In C++, return 0 or return EXIT_SUCCESS (defined in cstdlib) indicates successful termination. return 1 doesn't really have much meaning (it may just happen to be the value of EXIT_SUCCESS or EXIT_FAILURE, but if it did that'd be coincidence), and from my perspective when I see return 1 I think "not returning 0, there must've been an error." Which hardly seems to be the case in your benchmarking app.

And I talked about the C libraries because... it's C++, not C. They're two different languages, and when someone pretends they're the same I start doubting that person.

Anyway, I'm done derailing this thread. Discussing this further would be done better through PMs or a new thread.