Boost logo

Boost :

From: Niels Dekker - mail address until 2008-12-31 (nd_mail_address_valid_until_2008-12-31_at_[hidden])
Date: 2008-08-16 09:47:17


Joseph Gauterin wrote:
> the important thing is that a call to boost::swap swaps its
> arguments, not the exact mechanism by which it swaps the arguments.

I would like to add some extra checks to the existing test programs in
trunk/libs/utility/swap/test, checking if boost::swap indeed swaps its
arguments:

  swap_test_class object1 = initial_value1;
  swap_test_class object2 = initial_value2;
  
  boost::swap(object1,object2);
  
  BOOST_CHECK(object1 == initial_value2);
  BOOST_CHECK(object2 == initial_value1);

Therefore, your swap_test_class would need to become EqualComparible,
and it would need to have some data. Hope you think it's okay if I
apply the attached patch... :-)

> Also, there's a clear precedent with the standard library - the
> algorithm are all named after what they do, not how they do it (swap,
> sort, remove etc).

The Standard actually describes std::swap in terms of exchanging values:

  template<class T> void swap(T& a, T& b);
  ...
  Effects: Exchanges values stored in two locations.

So we could consider renaming "swap_impl" to "exchange_values". (And
have boost::swap calling exchange_values.) What do you think?

> >// - swap_impl is put outside the boost namespace, to avoid infinite
> >// recursion (stack overflow) when swapping objects of a primitive type.

> Does the infinite recursion only happen using primitive types - and if
> so do you know why?

I just tested moving ::boost_swap_impl::swap_impl to ::boost::swap_impl
on my local copy, and running utility/swap/test for MSVC 7.1, MSVC 9.0,
and Borland 5.82.

On MSVC (both 7.1 and 9.0), moving ::boost_swap_impl::swap_impl to
::boost::swap_impl introduces test failures

> If it does, then it might be possible to move the boost_swap_impl
> namespace inside namespace boost using some sort of SFINAE technique
> to explicitly call std::swap for primitive types.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk