[boost] C++ Manifesto

Subject: [boost] C++ Manifesto
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-09-10 09:25:12

I wrote: A problem seems to be that we are trying to be meta-meta when meta-
alone suffices.

> The GCC frontend hasn't been integrated into mainline GCC, the LLVM
> frontend is beta and similarly lives out of tree. A substantial,
> incompatible, rewrite of the language is currently in progress.
>

The same can be said for C++0x.  And LLVM is not in beta w.r.t Apple.

>
> I've used D for some fun side projects, it is a nicer language than C++.
> However, would I suggest using it at work, and risking a major, long-living
> software project on it? Unfortunatly not yet, and most people I've
> personally spoken to agree.
>

I am speaking out of my backside when I say anything on this matter, as I
have not written anything substantial in D.

But my original point remains: why not? There are no tablets written in
stone stating Thou Shalt Write In C++. Sure, there are many people that are
"language lawyers" and understand the finer intricacies of ADL and that is
their livelihood. Great for them.

Most of us understand (or could understand) most of boost. It isn't that
hard - most of the "chicanery" is to do with xplat systems creating
code-paths that even the original authors don't understand.

The rest of the magic is in Spirit and similar expression-template-based
systems that are only hard to understand because of their working domain. If
they were written procedurally, they would be fine, or if they were written
in ML they would be fine but because they are written in a strange mixture
of bastardised C++ they are esoteric and deemed to be "excellent C++".

I'm sorry. I don't think that Spirit is excellent C++. I think it is
terribly clever C++ and I think that it represents a disservice to the C++
community. Further, I think it has singularly set back language development
by years. The damage is untold - if only there was active C++ support for a
system like ANTLR for the past few years rather than Spirit then maybe we
wouldn't be in the mess we are in now.

To be clear, I don't mean any disrespect to Joel or to the Spirit2 code-base
per se. I just don't think that the C++ compiler was ever meant to be a
language tool. I personally have witnessed at least two groups of coders
reject a DSL-based solution because they thought that to do so "correctly"
would mean using Boost.Spirit, which was beyond them. Meanwhile, ANTLR has
no C++ support. It's a crying shame. Why is there no Boost.ANTLR?

The question then stands: why stick with C++ for everything? What can D do
in similar circumstances? (I know the immediate answer is "we don't use D"
but can we please put that aside for a year).

I don't know. I haven't used it. I have nothing to do with Digital Mars or
Alex. I care only about writing effective code.

I feel that C++?? is becoming just that. It doesn't matter that I can
(eventually) understand the latest boost library, or the latest boost
technique. What matters is what is the best way to write efficient code?

Because I can agree with you, when you think that you are writing a lot of
boilerplate nonsense to get basic things done.

Move semantics and the problems that Ion is having is a case in point. I
don't mean to be a misery-guts, but after having looking deeply at the
issues I really don't see a way that it can be done without a language
change. C++ is a fine language, but seriously, the authors didn't have any
idea on how we'd use it and the differences are compounding exponentially.

When C++ is no longer the best way (and yes, that is a "when" not an "if"),
I would like to think that I am open-minded enough to be on that wave. Is
that time sooner rather than later?

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*?

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?

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.

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

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

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

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.

What do you use?  Which parts of boost are good to use with least impact?

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.

I am in the position now to decide what will be the language for the next
game made in company A. I am strongly tempted to make the core in C# with
callouts to C++ libs for physics and render. 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.

Regards,
Christian.