Re: [boost] Boost libraries for 'TR2'

Subject: Re: [boost] Boost libraries for 'TR2'
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-11-18 04:53:44

On 11/18/2011 2:09 PM, Robert Ramey wrote:
> 
> "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote in message 
> news:4EC44785.5040401_at_wanadoo.fr...
>> Hi,
>>
>> just out of curiosity, which Boost libraries could we expect to be 
>> proposed for the TR2 (or whatever the new C++ run for new libraries will 
>> be called)?
>>
>> Who is working on a concrete proposal? Which libraries would you like to 
>> be proposed?
>>
>>
>> I would like myself to see between others: Accumulators, Any, Asio, 
>> DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, 
>> Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread 
>> (shared locks), Units and Variant.
> 
> Just out of curiosity - suppose someone had a library whose implementation
> depended heavily upon some other libraries like mpl, boost/iterators and 
> boost/config.
> How could such a library get included in the standard if the other 
> pre-requisite
> libraries aren't in the standard.
> 
> I realise that the standard specifies only the interface.  Taking the fusion
> library as just an example, it's not really practical to implement such a 
> thing
> without mpl, config, pre-processor, and likely others.
> 
> When I see the list above, I'm wondering if the concept of standard library
> isn't getting out of hand. Or maybe the standandard library needs to be
> divided into more than one tier- low level facilities like smart pointer and
> "application like" facilities like asio.
> 
> More to the point, if something like fusion is added to the standard and
> the interface is defined - is someone actually going to re-implement it?
> That would seem unbelievable to me.

FWIW, Fusion can be implemented without its current dependencies
especially in the C++11 world. I've been contemplating such an
exercise. Such a no-dependency library would rock in terms of
compile time. Complexity shouldn't hurt either. IMO, the needed
infrastructure was largely in part due to limitations of the
language and difficulty in implementing certain constructs
(e.g. result_of and type sequences to name two). I believe C++11
can simplify a lot of the current code.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com