vicente.botet wrote:
Hi Robert,
If its a useful function which is shared by several libraries, it should be in something like: "unreviewed". And of course these should have thier test and documenations in the corresponding "lib" subdirectory.
I disagree here. If is is useful to others it should be proposed for review if it can not be integrated in an existing library. Otherwise it is up to the author that is using the detail part to maintain it, at least respect to the user of her/his library.
In detail, one finds some things like: utf8, lightweight test, among other things. In fact I use both of test so I know they are used by multiple libraries. So this raises the question as to where they should go. They are in fact unreviewed and they are not an implementation detail of only one library. They're not going away. The main thing that bothers me is that there is no place for their documentation, tests, etc. 'utility" would be fine except for the fact that they are unreviewed - so that's why I picked "unreviewed.
Why do we need to install part of Boost.
As boost get's bigger and bigger, the probablilty of failure to install and pass tests gets larger and larger. So if someone wants to use just one library to start he has to do the whole thing. If he could do it one are a few libraries at at time it would be much easier to ease into boost. Also, there are many platforms (embedded and ?) which could not run all of boost. If one has one of those, he has to install all the libraries and then read and discard all the failures - a time consuming and confidence shaking excercise. I would expect the in the future one would be needing one component - say shared_ptr, and just install that. just installing that (and it's dependents) would take probably only a minute - maybe two if one ran the tests and the user would be right where he needs to be. Also, one would not have any accidental dependcies on a bunch of other code. There a lot's of reasons to make granularity finer.
Boost is a whole
It is now. That's what I believe will have to change, My view is that it's becoming an obstacle to growth and usablility because installation, testing, maintenance and deployment are not scalable. Robert Ramey