🚀 go-pugleaf

In article <4k0m72$gm1@jabba.lehman.com>, ajay@lehman.com (Ajay Kamdar) wrote:

> ... it is obvious that trying to support
> the Taligent idiom [transfer of resource ownership] is requiring
> considerable work, and
> it is not clear that a clean solution exists. Greg and others
> have tried admirably to come up with solutions, but the extensive
> discussions in this newsgroup make it obvious that each of
> the solutions leaves many things to be desired. Irrespecitve
> of what the Taligent experience has been with this idiom,
> the collective experience of the people who have participated
> in these discussions (a sum total that far exceeds whatever
> Taligent can muster) clearly indicates that the form required
> to support the Taligent idiom leaves a lot to be desired.

Well, no.  There were more people actively using smart pointers
at Taligent than there have been people discussing them here.
But that isn't really the point...

> So why not forget about trying to support the Taligent idiom
> in auto_ptr and stay with the original intent of providing a
> standardized idiom for exception safety? There is no reason
> why the two separate idioms should be married together in
> one class. What ever happened to the concept of using the
> right tool for the right job? It is perfectly ok
> for Taligent to impose a particular idiom on Taligent users
> -- the users of the Taligent framework have a choice whether
> to use the framework or not. But it is another matter to stuff
> a questionable form of the idiom down the throats of every C++
> user by making it a part of the standard auto_ptr.

Transfer of ownership is not the end goal - the end goal is
to make auto_ptr useful for the "resource acquisition is
initialization" idiom.  That is very painful without transfer
of ownership.

In particular, if you want to do the resource acquisition in a
function called by the function which needs to hold the resource,
there is no good exception-safe way to pass the pointer from the
callee to the caller.

You can get close (at some cost in clarity):

    extern get_X(auto_ptr<X> &);
    void f() {
        auto_ptr<X> ptr;
        get_X(ptr);   // uses reset() to pass the pointer
        ...
    }

but this requires very careful coding in get_X:

    void get_X(auto_ptr<X> &ptr) {
        X *p = new X;
        // WARNING: DO NOT RISK AN EXCEPTION AT THIS POINT
        ptr.reset(p);
        return;
    }

which is now extremely error-prone.  Alternatively:

    void get_X(auto_ptr<X> &ptr) {
        auto_ptr<X> p = new X;
        ptr.reset(p.release());
        return;
    }

but this requires dealing with details of auto_ptr one should
not need to worry about in ordinary code.

With copy semantics:

    extern auto_ptr<X> get_X();
    void f() {
        auto_ptr<X> ptr = get_X();
        ...
    }

   auto_ptr<X> get_X() {
        return auto_ptr<X>(new X);
    }

The easier it is to use auto_ptr, the more often it will be
used when it is needed - and the more often it will be used
correctly.


-- Bill Gibbons (formerly at Taligent)

-- 
Bill Gibbons
bill@gibbons.org
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]