Boost logo

Boost :

Subject: Re: [boost] question about C++11 guidelines
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-05-03 16:14:33


Doug Gregor wrote:
> On Wed, May 2, 2012 at 3:01 PM, Eric Niebler <eric_at_[hidden]>
> wrote:
>> Say I'm rewriting an existing Boost library and targeting C++11
>> users. I plan to ship C++03 and C++11 versions of my library
>> side-by-side, so back-compat isn't an issue for the new code. Is
>> there a reason to prefer using Boost's versions of utilities like
>> enable_if, type traits, integral constant wrappers (e.g. mpl::int_),
>> tuples, etc., over the now-standard ones?
>>
>> I'm leaning toward using std:: where I can, and falling back on
>> Boost's versions only when there is a compelling reason.
>
> Boost in C++11 should use the std:: facilities.
>
> Boost provides existing practice and reference implementations to aid
> in the standardization process. But we don't actually realize the
> benefits of standardizing Boost components if we never move off our
> own reference implementations. If there is a problem with a vendor's
> implementation of these std:: facilities, we should help that vendor
> get the implementation right.

But was a library author do in the meantime? How does one make
on body of code which works on all platforms? To me the best
would be that libraries make their requirements more explicit. Something
like:

library X Presumes C++11 compatibility
library Y presumes C++03 compatibility

Of course in practice since no compiler actually supports the above
statements would have to be modifed to:

library X : works with compiler A, B, C & D with the C++11 switch on
library Y : works with compiler I, J, K, ...

Which is more or less the situation we have now. Basically a library
author has to decide which group of compilers he's going to support.
Some libraries need to be almost universal (e.g. shared_ptr) while
others don't have to be (e.g. fusion) since they're audience is more narrow.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk