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@rrsd.com> 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