Re: [boost] question about C++11 guidelines

Subject: Re: [boost] question about C++11 guidelines
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2012-05-06 10:41:08

On May 4, 2012, at 1:53 AM, Ivan Le Lann <ivan.lelann_at_[hidden]> wrote:

> 
> 
> ----- Mail original -----
>> De: "Doug Gregor" <doug.gregor_at_[hidden]>
>> À: boost_at_[hidden]
>> Envoyé: Jeudi 3 Mai 2012 18:27:31
>> Objet: Re: [boost] question about C++11 guidelines
>> 
>> 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.
> 
> Obviously but the problem is what "use" means. It's not because you 
> call it "boost::shared_ptr" that it does not use, alias or wrap C++11.
> 
> And boost::shared_ptr and boost::enable_if may be new beasts in the future.

That would be unfortunate. The whole point of standardization is to get everyone to use the same components with the same features. If we go off and extend boost::shared_ptr to make it different from std::shared_ptr, we've done the C++ community a double disservice because we ourselves have created two de facto standards for shared_ptr: the actual standard and Boost itself. 

> If you wrote std::shared_ptr and std::enable_if everywhere in your code,
> you won't be able to benefit from that.

Or be hurt by it. 

It's time to leave the already-standardized Boost components' interfaces alone. Whatever little advantages we get from further improvements are wiped out by the disadvantages of continued fragmentation. Besides, aren't there a thousand other libraries to build and improve? ;)

  - Doug