on Mon Aug 25 2008, "Niels Dekker - mail address until 2008-12-31" <nd_mail_address_valid_until_2008-12-31-AT-xs4all.nl> 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 compiler. -- Dave Abrahams BoostPro Computing http://www.boostpro.com