🚀 go-pugleaf

In article <gregorDpFBCt.A5@netcom.com> gregor@netcom.com (Greg
Colvin) writes:

> Please remember that auto_ptr is designed to make sure that pointers
> are deleted when exceptions are thrown, not to be sure that already
> deleted pointers are not misused.  The semantics of auto_ptr are
> intentionally "as close as possible" to ordinary pointers: if you
> use a pointer that is already deleted the behaviour is undefined,
> and the same for auto_ptr; if you use a pointer that is owned by
> another object (i.e. will be deleted by that objects destructor) the
> behaviour is well defined as long as the pointer remains valid, and
> the same for auto_ptr; you cannot tell at runtime whether a pointer
> is valid, and the same for auto_ptr.

My original question was "Did the committee explicitly decide to allow
dereferencing of non-owning auto_ptrs?  If so, what is the rationale
behind this?"  It seems to me Greg's answer is "Yes, because that's
what ordinary pointers do."  I cannot understand this.  Why allow a
dangerous operation just because ordinary pointers do not prohibit it?

Please note:

1. The previous (April '95 DWP) incarnation of auto_ptr did not forbid
to have a second, non-owning, pointer to the owned object.  However,
in order to get one, we had to explicitly call the get() member
function, which returns an ordinary pointer.  In my opinion, requiring
the user to go through all this trouble was a reasonable safeguard
against accessing released memory and unintended aliasing.  In the new
incarnation, there are no such guarantees: an auto_ptr silently
changes into a zombie pointer as a side effect of a copy operation.

2.  We all have to pay the price for the committee's decision.  The
new implementation is about twice as complicated - up to the point
where almost no existing compiler can handle it - and half as
efficient.  Furthermore, dropping a guarantee always breaks existing
code.

What I definitely do not understand is why the new auto_ptr template
doesn't even allow us to query if it is actually owning the object
pointed to. 

> What you can do is design your code so that you know who owns each
> object when.  The auto_ptr template can help you implement such
> designs safely.  If you cannot design your code to work with
> auto_ptr you probably need garbage collection of some form.

auto_ptr may have been designed to provide only limited functionality,
but since it is the only heap object management facility in the
standard, it will be used in many different contexts.  Therefore, I
think it is quite resonable to ask how easy it is to abuse it.  What I
dislike about the new auto_ptr incarnation is that it is even easier
to abuse than the old one.

- Wil
---
[ 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                             ]