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

Subject: Re: [boost] question about C++11 guidelines
From: Eric Niebler (eric_at_[hidden])
Date: 2012-05-03 03:50:07

On 5/3/2012 12:27 AM, Roland Bock wrote:
> On 2012-05-03 08:15, Andrey Semashev wrote:
>> 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?

I'm going on the naive assumption that each platform will have
intelligently implemented C++11 library components. If that turns out
not the be the case, then I will fall back on the Boost stuff, but only
as needed.

>> 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

This falls into the "falling back on boost only when there is a
compelling reason" bucket.

>> know how it works (i.e. potential pitfalls and advantages) and it's
>> available everywhere.

As I said, I'm targeting C++11 so I'm not really worried about back-compat.

> On the other hand, why did boost spend all the efforts to make these
> things part of the new standard if not to use them?
> 
> IMHO, if the new code is targeted to C++11, it should use it. And if
> this exposes bugs or less efficient implementations in some compilers:
> Cool! It will help compiler vendors and other libraries a lot!

Right.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com