🚀 go-pugleaf

In article <009A04DA6A831C40.49800EAC@ittpub.nl>,
Wil Evers <wil@ittpub.nl> wrote:
>Hi,
>
>In article <gregorDp23ts.Axt@netcom.com> gregor@netcom.com (Greg Colvin)
>writes:
>
>> In Santa Cruz we decided to change the auto_ptr copy semantics to
>> allow returns of auto_ptr from functions.  Following is a simple
>> implementation.  
>
>This is a terrible state of affairs, especially when we realize
>auto_ptr is the *only* smart pointer we have in the standard library.
>In my opinion, it should be renamed to zombie_ptr if it is to keep its
>new semantics.

I am afraid I agree that this is not going in the right direction.

In a post back in February, Greg Colvin provided the history
and motivation behind the auto_ptr proposal. To reiterate
what he said then, the auto_ptr tries to support the following
idioms:

  1. "Resource acquisition is intialization".

     This idiom is intended to very considerably simplify the
     exception safety of code which allocates some resource,
     operates upon this resource, invokes other functions 
     which could potentially throw an exception, and then
     cleans up the resouce before exiting.

     This idiom can be supported cleanly and elegantly by
     the auto_ptr template, without any change to the
     language or the other issues which are causing quite
     a discussion.

     This idiom was the *only* idiom which auto_ptr was
     intended to originally support.


  2. Transfer of resource ownership.

     This idiom can be used two ways:

     2a. The "sink" is called with a resource acquired by
	 the the caller, and the sink is responsible for
	 deleting the resource.

     2b. The "source" (the caller) is returned a resource
	 acquired by the callee, and the caller is responsible
	 for deleting the resource.

     This idiom requires the auto_ptr to have copy semantics,
     and is the source of all the debate. This idiom was *not*
     the original intent of auto_ptr, and was added in response
     to some experiences reported by Taligent.


Given this background, it is obvious that trying to support
the Taligent idiom 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.

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.

IMHO, it would be a grave mistake for the standardization
comittee to agree upon an auto_ptr which tries to support
the Taligent idiom. Here's what I suggest:

   + The standard auto_ptr should address only the
     "resource acquisition is initialization" idiom. It should
     not try have any copy semantics.

   + The supporters of the Taligent idiom can, if they feel
     strongly about it, propose a taligent_ptr class which
     addresses the transfer of resource ownership idiom.
     Programmers can then decide whether to use it or not
     on its own merit independently of any thing else.

-- 
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
Lehman Brothers    |    Phone: (201) 524-5048     |
---
[ 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                             ]