Subject: Re: [boost] Boost Evolution
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-10-08 17:20:25
David Abrahams wrote:
> At Fri, 8 Oct 2010 10:46:33 -0800,
> Robert Ramey wrote:
>> Boost is getting bigger and bigger. This is a good thing.
>> The Boost header directory and boost namespace is also getting
>> bigger and bigger. This is starting to become a problem.
> Specifically, how? I don't like it either, but I'd like to know what
> the real-world effects are.
a) >> As boost get's bigger and bigger, it gets harder and harder to
>> install just a part of it. But installing just a part of it is what
>> need to become confident about it.
b) suppose I start with my "small" embedded system. Now I need
shared_ptr and so I install boost. Now when something unexpected
happens, I've now got to consider that that something is among
thousands of lines of code that I for all practical purpposes I can't
inspect. The giant size of boost means that I can accidently
inject dependencies without being aware of them. Even if it
never happens, I now have to consider this possibility everytime
I have a problem.
c) It's a real obstacle to convincing programmers to install and
experiment with boost.
These are already problems right now. They'll only get worse.
>> c) a couple of "catch all" namespaces/headers would be required such
>> as "utility" for small libraries.
>> I'm somewhat confused about "detail". If it's an implemenation
>> of a particular library it should be in that library. If its a
>> useful function
>> which is shared by several libraries, it should be in something like:
> But in general it's not unreviewed code. It was usually part of a
> library that passed review, and then the code was factored out. So it
> doesn't have the same standing as a Boost library, and it may not have
> any user-level documentation, because... it's an implementation detail
> of various Boost libraries.
Hmmmm - if its reviewed and placed in a "global" namespace like
boost::detail why not just include it in boost::utility then? if its used
for just one library, then why not make it a part of that one library
rather than putting it in a global namespace?
>> And of course these should have thier test and documenations
>> in the corresponding "lib" subdirectory.
Which we don't currently have this for "detail" components.
>> I realize that we've been circling around this topic for a while, I
>> just want to keep it alive.
> Don't worry, Ryppl isn't dead either; it's just been quiet for a while
I see this evolution as something necessary on it's own. Rypple
may or maynot occur, but I think boost should evolve in this
direction regardless. For now, I'm proposing these changes
only for new libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk