But if this was my first look at boost, I'd delete it right away. Seriously, on this platform are millions of C++ users that only heard very vague rumours of C++ being standardized -- if they heard about it at all. Those don't see much benefit it smart pointers, consider the MPL to be black art, and can't be bothered if it isn't really easy to use.
Schobi
--
But for these "millions of C++ users" Boost is not the right choice. The exciting thing about Boost is that it is Avantgarde, a good deal of interesting research(!), and not compromising on quality. That's at least my understanding of Boost. Sure, it would be nice to have this additional layer for beginners, but that simply seems not to be feasible. Sure, documentation of Boost can be improved (and the installation guides as far as I know them are really not enough (I say this as a Linux user)), but that's true for ALL existing software. It's just hard to write about technical material, and, as I know it from our students, for example almost all computer science students have to be considered as near analphabets, so it's not so easy to get the documentation written. (But GUI's are at the root of that problem: They destroy understanding.) Here comes one proposal: If it would be easier for boost members to edit existing documentation, then at least I could contribute quite a bit. But I mean "really easy", for example a wiki with the current documentation, where one can just goes and change it (and there is somebody responsible for each (sub-)library); this could really improve documentation a lot. (One should have as a general guideline, that additions are conservative, that is, they only extend and correct the given text, but they do not eliminate something (because one doesn't like the style etc.). And my focus here is really on the *text*, which quite often assumes some common ground, which more often than not is not given.) Here one example (about documentation in general): I know of one MSc project of a colleague, based on Spirit, which nearly failed because the student didn't have the right understanding what Spirit really was supposed to do (that "recursive decent parser thing"), and also I fall into the same trap (but it only cost me a few hours). So an easy thing would be to go to the *current* Spirit documentation, and add at one or two places a few warnings. This could help a lot. But first writing an e-mail, explaining all this, etc. costs too much time. Just adding these sentences on a wiki, that should be it, and the maintainer then is automatically alerted. Oliver