🚀 go-pugleaf

In article mKQD@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su>
writes:
>Hi!
>I would like to suggest returning to the definition of auto_ptr. The fact
>is, in current form it is almost unusable for most things due to its
>underlining concept of a single strict ownership. Actually, we need
>multiple-instance auto_ptr. If, as I suspect, its inclusion was prevented
>by the problem of efficiently allocating the counter in ref.counted
>pointer, then we could parameterize auto_ptr WRT not only the type, but
>allocator as well. Also, we could use doubly-linked list instead. And
>anyway, it is the implementation problem!

That point has been beaten to death in the C++ committee and also in
this forum. Some people felt an auto_ptr should be able to have multiple
owners, but people with experience with this kind of design persuaded
the committee that auto_ptrs are too hard to use unless they can have
only a single owner. Thus, ownership is transferred upon copying.

That is, single ownership is a deliberate design decision based on the
semantics an auto-ptr should have. It is not an implementation issue.

Unless someone can present new evidence that shows the arguments in favor
of single ownership are wrong, and in addition shows that multiple
ownership is always better, this subject won't be reopened in the committee.

(Yes, examples are known where multiple ownership does what you want.
That doesn't mean it is overall the best design. And nothing prevents
you from writing your own multiple-owner class.)

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]