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

Subject: Re: [boost] question about C++11 guidelines
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-05-04 01:44:56

Le 03/05/12 08:15, Andrey Semashev a écrit :
> On Thu, May 3, 2012 at 10:30 AM, Robert Ramey<ramey_at_[hidden]>  wrote:
>> Eric Niebler 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.
>> Isn't easier to just use the boost versions knowing that they
>> will be implemented in the most efficient/appropriate way
>> for the compiler in question?
> Although I wouldn't be so sure about the "most efficient/appropriate"
> part, I would still use boost for several reasons. This is the code
> we're in control of (so if there are bugs we can fix them ASAP), we
> know how it works (i.e. potential pitfalls and advantages) and it's
> available everywhere.
>
>
There is an additional advantage, we can extend it intrusively to try 
new improvements to the standard libraries. E.g. I don't see how we can 
implement thread cancelation/interruption on top of the standard Thread 
(well I have not tried it ;-)), or shared mutex without modifying the 
unique_lock. I guess that there are a lot of more examples. These 
extensions to the standard should be stated explicitly in the 
documentation.

IMO, every Boost library that has a counterpart in the standard should 
comply with the standard as much as possible and should use the standard 
whenever it is possible (that is the class/function is available and the 
library don't introduce extensions on them). Any deviation from the 
standard could be seen as a defect and should either be fixed or 
described explicitly as a limitation on the documentation.

Best,
Vicente