Subject: Re: [boost] C++ Manifesto
From: Paul Baxter (pauljbaxter_at_[hidden])
Date: 2009-09-10 17:32:42
< Some extracts that ring true with me, my emphasis applied >
> I'm sorry. I don't think that Spirit is excellent C++. I think it is
> terribly clever C++
> 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?
> When C++ is no longer the best way (and yes, that is a "when" not an
> I would like to think that I am open-minded enough to be on that wave. Is
> that time sooner rather than later?
> 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
> their use of weak_ptr<> and locking etc with that.
> What do you use? Which parts of boost are good to use with least impact?
> I am
> clearly frustrated with the potential of both boost and C++ in general.
> it makes me wonder if C++ is really what the real-time world needs.
I enjoyed and sympathised with pretty much everything you wrote.
I want to separate the C++ aspects from the Boost-specific ones.
At present I'm not sure an alternative language exists that is mature, cross
platform with an appropriately large, diverse, supportive community to
provide programmer support in terms of tools, skills availability.
I also still shudder that many advanced techniques rely on an enhanced C
Preprocessor for their magic. If we want compile time and runtime behaviour,
a language ought to support both, without clunky but clever (albeit mostly
hidden from the user) techniques.
Regarding the ecosystem surrounding a library, I compare C++'s progress with
languages such as Python and see C++ as a poor relation in terms of tools to
solve real world problems.
The focus does seem to be on creating new and novel techniques rather than
solving problems or providing cookbooks on how to use these tools to make
things easier. Arguably Boost was looking to the wider community and user
base to develop the 'user guides' while library developers have a different
agenda, focussing on the best interface and implementation.
IMO the C++ standardisation process in general and Boost by association may
suffer from an academic outlook that prefers to deliver well-crafted items
years too late. Boost was supposed to be a test bed and experimental ground
but still tries to be too perfect in creating the ultimate library in each
I'd prefer to see more support, mentoring and advice and a shelter for
promoting and improving many more libraries. Perhaps a second tier of
toolkits that let evolution sort out more of what is right for programmers?
By this I know we have an area for such libraries, but what web site support
do we have to 'advertise, extol or document' such fledgling libs? Perhaps
more of the web site could provide pointers to such libraries?
As an example, consider the library 'property tree'. Its interface and
implementation weren't and aren't perfect but they solve a real-world
problem in the absence of an alternative. There was a lot of debate that an
imperfect library perhaps shouldn't be part of Boost. Thankfully it got
accepted and thanks to Sebastian for moving it forward recently.
Boost should support and encourage these kinds of libraries even if perhaps
not candidates for C++1X material.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk