Re: [boost] C++ Manifesto

Subject: Re: [boost] C++ Manifesto
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-09-10 12:42:28

Christian Schladetsch wrote:

> Say you want to write a parser/AST walker/executor for a basic language with
> scoped variables and continuations. Is Boost.Spirit the best way to do so?
> Is it *really*?

Depends.
The main advantage of Boost.Spirit is that it's embedded in C++, making 
it somewhat easier than deploying regular parser generators.

> Say you want to write an object factory with persistent objects. Is
> Boost.Serialisation and Boost.Function the best way forward? How will you
> you store the functions?

I don't even know how you can serialize a function object, especially if 
you lost its type information.

> Say you want automatic resource management. shared_ptr<> doesn't cut it. It
> is too slow for single-threaded and at the same time doesn't deal with
> cycles.

shared_ptr is meant for shared ownership, not automatic resource management.

Plus, you can get automatic resource management using the stack (haha! 
Yes I know, that's not what you meant).

And finally, cycles are impossible to support on regular types by design 
in C++ due to destructors. You'd need to deal with a special category of 
types, like C++/CLI does.
As you can see, this is *nothing* like what shared_ptr provides. It 
doesn't fit your problem at all, because it's simply not meant to.

However, there could be a solution to your problem. It just doesn't 
exist in boost (even though some people offered to have their solutions 
included, but the whole formal review thing is making it hard to 
contribute new libraries).

> Say you want to write a geometry library. Ok, stop right there....

If you want to write a geometry library, it may be a good idea to get it 
in Boost to make it more widespread, yes, unless you really wish not to 
be affiliated with Boost.

I don't really understand that point.

> Is Boost.Graph the best way to make a basic DAG?

It's a way.
Consider the alternatives and compare them. As I understand, the main 
advantage of Boost.Graph is that you can reuse the generic algorithms.

> I've tried all these systems. They work, there is no doubt. Do they work
> well, in practice?

The Boost libraries are not supposed to be the ultimate best solution to 
a problem domain.
They're simply specific solutions for specific problems, with advantages 
and drawbacks. It's up to you to select the solution you think is best 
for your problem.

The advantage of Boost libraries is that they usually fulfill certain 
base criteria, like being exception-safe, generic, and non-intrusive.
Obviously, while those qualities are nice (especially to language 
lawyers), they're certainly not the most important ones in choosing a 
solution.

> Has there been any real-world review of the efficacy of boost libraries in
> general? I'm sure there has, as many here could attest, but this is a biased
> sample set. I wonder how much and what aspects of boost are used in the
> wider community?
> 
> I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other
> bits and pieces. No-one in my team uses anything other than foreach and
> shared_ptr - and there is a lot of confusion I have to deal with relating to
> their use of weak_ptr<> and locking etc with that. It seems that 5 years ago
> I had to argue that boost was Ok to use, and I still feel like I am saying
> the same things. I am approaching the stage where I wonder why I continue to
> apologise for it.

AFAIK, the only thing that is heavily widespread is shared_ptr, which is 
heavily misused as a mean to code Java-style and emulate a garbage 
collector.

Boost.Function and Boost.Bind are also used quite a lot, mainly because 
they are required to deal with the STL easily, but most coders still 
don't understand how they work and worse, what they are (overusage of 
boost::function when there is no need for type erasure whatsoever is 
fairly common).

Notice how these things are now part of TR1. Other parts that were 
adapted in TR1 are fairly used as well.

Apart from that, I know the memory pool allocator is popular.

Usage of more specific or bigger libraries is what's more scarce. People 
use the little general tools way more. Which is perfectly logical; it's 
easier to bring in small tools in a project than a dependency on a 
fully-fledged library.

> This has turned into a manifesto against boost. I didn't mean that to be the
> case when I started, but so be it. I come from the real world, and there are
> real programmers that just don't know and don't want to deal with problems
> they can't solve. As a lead, I have to make technology decisions and I am
> clearly frustrated with the potential of both boost and C++ in general.
> Sometimes I think that it would be easier to just change language completely
> to C#/asm or D/C++/asm.

Well, no one is forcing you to use C++. C++ has quite a few advantages 
that make it a better general-purpose language than others, especially 
when efficiency is a concern -- and a few drawbacks as well, but as a 
C++ lover I don't really see them --, but if you find tools in other 
languages that you think are better that the ones that exist in C++, and 
you don't want to code your own tools, then it's really a better idea to 
use that other language.

> I am in the position now to decide what will be the language for the next
> game made in company A.

Games are often written in a dialect without exceptions. If you're in 
this case, then you can dismiss huge portions of Boost, since that 
dialect is really quite different from standard C++.

> Personally, after 20-odd years
> and still seeing the likes of Lucanus swing on the rope with his geometry
> lib, it makes me wonder if C++ is really what the real-time world needs.

I didn't follow everything that happened with Lucanus' library. 
Personally I won't use it since I have no use for polygons with integral 
coordinates.
What is the problem exactly? The QA review is too harsh?