Re: why a member "swap" function shouldn't throw?

On Jun 15, 2:21 pm, Jess <w...@hotmail.com> wrote:


More convention that anything else. A non-member function can
usually not to much else but to use the conventional algorithm:

    T tmp( a ) ;
    a = b ;
    b = tmp ;

This involves constructing a new object (the tmp), which can
often throw. A member function, however, has access to the
underlying types: pointers, etc., and can usually avoid deep
copy by just swapping the pointers. This is not only
significantly faster in some cases, but swapping two pointers,
even with the above algorithm, will not throw.

Being able to swap without throwing means that we can
effectively copy without throwing: if I have something like:

    T x, y ;
    x.swap( y ) ;

has the same effect on x as copying y into x, except that a real
copy might throw (since it would deep copy all of y---here that
is avoided by allowing y to become a copy of x, effectively
swapping ownership of any resources, rather than allocating them
new).

This is in turn very useful for things like operator=. Consider
an object that uses the compilation firewall idiom:

    // Classical op=
    T&
    T::operator=( T const& rhs )
    {
        if ( this != &rhs ) {
            delete pImpl ;
            pImpl = new Impl( *rhs.pImpl ) ;
            // What happens if the above line throws???
        }
        return *this ;
    }

    // Using swap.
    T&
    T::operator=( T const& rhs )
    {
        T tmp( rhs ) ; // Actual copy, and possible throw,
                            // occurs here.
        std::swap( tmp.pImpl, pImpl ) ;
                            // Now this is the actual copy, and
                            // tmp holds all our old resources.
        return *this ; // Destructs tmp, thus freeing our
                            // old resources.
    }

Of course, this can be done without swap; I could have just
copied the impl into a temporary pointer, deleted my pImpl, and
then assigned it with the results of the copy. (Which is still
the way I write something as simple as the compilation firewall
idiom.) Doing it this way becomes a bit more complicated,
however, when I have more members, all of which need the same
treatment. And since I'm actually swapping, why not make the
function available at the public interface level? That way, a
class which doesn't use the compilation firewall idiom, but uses
an instance of my class, can easily implement its own no-throw
version of swap. The benefit propagates.

Note, however, that all of this concerning swap is just a means
to an end, and in no way necessary. The important thing isn't
swap; it's having an assignment operator that doesn't leave the
object in an undefined state if copying something in it throws.
Having a no-throw version of swap is just a convenient and
conventional method of ensuring that this is posssible, and in
fact rather easy.

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34