Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-25 11:51:02

on Mon Aug 25 2008, "Niels Dekker - mail address until 2008-12-31" <> wrote:

> David Abrahams wrote:

>>> It's a pity that has_swap_overload<T> yields false negatives, when
>>> T has
>>> std as associated namespace.
>> It's easy enough to fix that with specialization, as my posted example
>> shows.
> Hmmm... So has_swap_overload<T> should have a specialization for each
> class template that has a template type parameter (allowing std as
> associated namespace of the template argument) and a custom
> swap. That's a pity.

What can I say; it's the best we can do.

>> IMO the best solution is like this:
>> std is an associated namespace of T
>> ? has_member_swap<T>
>> : has_nonmember_swap<T>
>> plus any specializations required to handle something like tr1::array
>> that might not have a member swap.
> FYI, the tr1::array that comes with VC9 SP1 /does/ have a member swap,
> as well as a swap overload.
> Anyway, I was also considering a more "lightweight" way to tweak
> MSVC's Swaptimization, merely based upon tr1::has_nothrow_copy (which
> is included VC9 SP1). Because when using MSVC9, whenever a function
> like vector<T>::push_back needs to reallocate, it moves its elements
> /either/ by copy-construction /or/ by default-construction + swap,
> depending on whether "Swaptimization" is turned on for type T. Isn't
> it reasonable to just do default-construction + swap, /unless/ T has
> no-throw copy-construction?

That's a massive pessimization for fundamental types and simple
composites: int, T*, pairs, tuples, std::complex, etc... not to mention
that has_nothrow_copy *has* to give false negatives, even on a smart

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at