Boost logo

Boost :

Subject: Re: [boost] is review system in place is extremely slow? (was Re:[rfc] rcpp)
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2010-02-24 18:55:27

On Wed, Feb 24, 2010 at 11:08 AM, joel falcou <joel.falcou_at_[hidden]> wrote:

> Robert Ramey wrote:
>> Vladimir Prus wrote:
>>> I'm the review manager of Boost.Task but the library is not ready
>>>> for review, because now Boost.Task depends on Boost.Move,
>>>> Boost.Fiber and Boost.Atomic (which is not yet on the review queue).
>>>> Maybe the review withards could add this on the schedule page.
>>> It's perfectly OK to move those 3 libraries to the 'detail' namespace
>>> of Boost.Task and have review as it is, as opposed to waiting. What
>>> do you think?
>> I think I caught hell for doing something similar in the serialization
>> library. I had to make a number of components such as
>> BOOST_STRONGTYPEDEF, state_saver, smart_cast, etc.
>> which I put into boost - (not detail) and year afterwards this
>> was raised as a huge problem. And this was even though the
>> components had been their through two reviews. So I would
>> be careful about doing this.
> This really seems to make the "have a layered boost" proposal sensible.
> We should definetively separate core boost tools and utility library from
> system wide
> scale libraries.
I have to agree with this. It is both annoying and unnecessary that if all
I want is one simple library, I have to have almost every other library on
my system.

Things like mpl, regex, preprocessor, variant, unordered, etc should
certainly be at a completely different layer than extremely high level
libraries like GIL, wave, etc.

How to define these layers is of course the question.

Perhaps a first step would be to carefully draw up a chart of the current
dependency graph between the entire set of libraries, and see what can be
extracted from there.

Boost list run by bdawes at, gregod at, cpdaniel at, john at