🚀 go-pugleaf

Hello!

clamage@Eng.Sun.COM (Steve Clamage) writes
>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.

Could you explain please? I understand that multi_ap may be harder to
implement, but using them are much simpler. Also, why is it called _copy_
constructor - it is in fact the _move_ constructor. (Generally, is it wise
to call X(X&) the copy constructor?)

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

I never said that strict/multiple ownership is an implementation issue. I
was talking about whether to implement multiple-ownership auto_ptrs using
ref.counting, list or something else.

>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.

The fact is, multiauto_ptrs can be used in every place where singleauto_ptr
can. The only possible drawback is the overhead in performance (negligible
as compared to memory allocation - especially for list implementation) and
storage (not so terrible as current compilers are not likely to put
single_ap in register anyway). On the other hand, single_ap can't be put in
STL container, can't be returned from the function, etc. Thus, the only its
possible use is ensuring that temporarily allocated object is deleted on
exception throw. (I would appreciate J.Kanze explaining the workarounds he
mentioned in another follow-up).

>(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.)

No offense intended, but what kind of argument is that? The entire C/C++
standard library (with the possible exception of the functions that
directly map to operating system calls) can (especially STL) be
reimplemented by each user - but what good will the standard then be?
I know the standards committee is doing a great and difficult job - but to
me such an attitude seems not very productive from the marketing point of
view.

              Best regards                    Genie

--
--------------------------------------------------------------------
Eugene V. Radchenko           Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                Fax: +7-(095)939-0290 
Ordinary mail:  Chair of Organic Chemistry, Department of Chemistry,
                      Moscow State University, 119899 Moscow, Russia
*****************  Disappearances are deceptive  *******************
---
[ 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. ]