🚀 go-pugleaf

In article <bill-0804960932250001@bgibbons.vip.best.com>,
Bill Gibbons <bill@gibbons.org> wrote:
>In article <4k4noe$igl@jabba.lehman.com>, ajay@lehman.com (Ajay Kamdar) wrote:
>
           [ snip ]
>> 
>> What's wrong with this? It doesn't require copy semantics
>> for auto_ptr. Yet both the caller and the callee
>> are exception safe and there is no loss of clarity.
>
>The problem is that it requires handling the raw pointer.
>Any time you transfer ownership by using release() to extract
>the raw pointer and then later use the raw pointer to
>construct another auto_ptr, there is a window where there is
>no exception safety.
>

You didn't say whether the example I gave was exception
safe or not. To reiterate the main points of the example
   + The caller directly initializes an auto_ptr with
     the returned value from the calee.
	 auto_ptr<X> ptr(get_X());

   + The callee releases the pointer from it's own
     auto_ptr in it's return statement.

No copy constructors are involved in the return. Hence
there is no possibility of an exception thrown from
a user defined copy constructor. So which window are
you referring to during which there is no exception
safety? I claim there is none.

>Of course you can carefully craft the code to make sure that
>no exceptions can be propagated during the window.  But there
>are two problems:

The example I gave is straight forward C++ programming; no
contortions or careful coding are required. The coding
pattern is simple enough that even junior programmers can
be taught to follow it easily.

Many other more useful extensions have been voted down by
the commitee on the grounds that the requested extension
could be implemented by existing mechanisms within the
language, even if those techniques required a fair
amount of work for the programmer. That stance cannot be
more applicable than in the case of the copy semantics
of auto_ptr -- there is simply no need for such semantics
because identical exception safety can be achieved by
a simple coding pattern.


>  (1) The maintainers of the code may not be as careful about
>      exception safety.  When everything is handled by
>      auto_ptr the risk of bugs creeping in is smaller.  Such
>      bugs are very difficult to find by testing.

Let's analyze which code is more difficult to maintain
and difficult to debug -- one using the copy semantics
of auto_ptr or one wihout copy semantics of auto_ptr.

  With copy semantics
  ===================
     If the copy ctor of auto_ptr taking a const auto_ptr&
     releases its raw pointer by casting away const,
     a programmer can accidentaly "lose" the raw pointer from
     within an auto_ptr -- even if the programmer was working
     with a const auto_ptr. This occurrs because auto_ptr
     violates const correctness and releases the raw pointer
     from the raw object.

     If the copy ctor of the auto_ptr taking a const auto_ptr&
     takes ownership of the raw pointer by casting away const
     and setting a flag (the latest proposal), the programmer
     can end up with a dangling pointer in the original
     auto_ptr if the new auto_ptr destructs first and deletes
     the raw pointer.

     It is possible that even extensive testing may not
     uncover such a problem on a less frequently traversed
     path in the code. Even if the path is traversed during
     testing, an error may or may not be generated when using
     the dangling pointer. Hence it is very possible that the
     error might escape it to production code.

  Without copy semantics of auto_ptr
  ==================================
    By eliminating any surprises due to the standard
    auto_ptr violating const correctness and leaving
    behind dangling pointers, program correctness is
    actually *improved*.

    But for the moment assume that even the simple pattern
    of using auto_ptr (release() on return in callee,
    direct initialization of auto_ptr in caller) is
    not followed correctly in some situation. Two major
    scenarios are possible:
       1. The error happens on a frequently travesed path
	  in the code, resulting in frequent ommission to
	  call delete.

	  In such situations, any of the many good leak
	  detectors on the market will show the error
	  during testing. The error will be fixed
	  before it reached production.

      2. The error is rare enough that it occurs only in
	 production.

	 By definition, the error is rare. So the application
	 will lose some resource each time. In practice,
	 each occurence of a failure to delete a resource is
	 not disastorous on its own, and the application will
	 go on.


So which one is better for the C++ programmer? An approach
which can lead to disastorous surprises at run-time
(auto_ptr with copy semantics approach) definitely does
not look the right choice under any stretch of imagination.


>  (2) The interface of get_X does not implicitly document
>      that the returned pointer refers to an object which
>      should be automatically deleted on an exception.
                               ^^^^^^^^^^^^^^^^^^^^^^^

Now we are getting close to what I firmly believe is the
real driving reason behind the push for auto_ptr to
have copy semantics.

Note that in the above quoted text, the reference to
exceptions in "deleted on an exception" is irrelevant.
In this case, the caller must always delete the ptr
allocated by the callee() -- exception or no exception.
Hence the use of auto_ptr in this case has nothing to
do with exception safety. But it has everything to do
with trying to replace documentation accompanying
get_X() saying that the caller must delete the pointer.

In isolation, it is a good goal to replace comments
which prescribe certain behavior with code constructs
which automatically take care of the issue. By
giving copy semantics to auto_ptr, the need to
document transfer of ownership of pointer is sourght
to be eliminated. I firmly believe that *this* is the
real reason behind the copy semantics of auto_ptr, with
exception safety only a peripheral issue at best. 
Unfortunately, it is abundantly clear that this attempt
at replacing documentation by giving auto_ptr copy
semantics has pretty high costs.

I strongly urge those who can do something about this
(those on the committee) to step back and separate
the wheat from the chaff. Don't make auto_ptr harder
to use for *all* C++ programmers by allowing it to
have copy semantics. Make a separate class
(taligent_ptr) which has the copy semantics for
those who *choose* to use it, rather than forcing
everyone to program with an unfortunate choice.
-- 
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 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]