Topic: Auto_ptrs in containers
Author: "Alain Coetmeur" <acoetmeur@icdc.caissedesdepots.fr>
Date: 1998/07/27 Raw View
Edward Diener a =E9crit dans le message <35ABEB29.56A6CA41@abraxis.com>...
>
>Edward Diener wrote:
>
>> Is it safe to use auto_ptrs in containers ? If not, what are the issue=
s ?
>Thanks to everyone.
>I read the GotW #25 and understand the issues involved.
what is this GotW?
[Mod note: "GotW" stands for "Guru of the Week" -- it refers to
a series of questions and answers posted to comp.lang.c++.moderated.
-- moderator (fjh).]
anyway :
thanks also for us.. we past last night on this...
the symptom was that the =3D=3D operator was impossible to generate
for map<> because auto_ptr does not have =3D=3D
I've though about generating a =3D=3D operator for auto_ptr,
or derive from auto_ptr, but in fact it seems a very dangerous affair, be=
cause
(if I understand you all here)
auto_ptr cannot cope with sharing property of a pointer with another,
and that in some container pointer can be copied in any order, so auto_pt=
r
cannot predict which is the good one...
If I understand well, and given we want a transparent destruction,
we have to develop our own smart pointer... are there any efficient one...
I've the intuition that
-either you put the refcount in the pointed to
object and you must derive from one base or generate an intermediate obje=
ct
to handle the refcount and the pointer
- or you keep a chained list of all pointers that are copied from each ot=
her
so that when one is destructed, it check it is not the last one, and remo=
ve itself from the list...
and this have a high overhead...
note that IMHO the second is possible because we can forbid to share the =
same object
from different smart_ptr initialized from the same native pointer... the =
only legal way
to share an object is by copying the smart_ptr object... which is that co=
ntainer do !
are ther any existing implementation... I think one can make
it in a few minutes (so did I, see below), but proven code is better...
template<T> shareable_auto_ptr
{
public:
explicit shareable_auto_ptr(T*p=3D0) throw()
: ptr(p),next(this),prev(this) {};
shareable_auto_ptr(shareable_auto_ptr<T>&sap )throw()
: ptr(sap.ptr),next(sap.next),prev(&sap) {sap->next=3Dthis;n=
ext->prev=3Dthis;};
~shareable_auto_ptr()
{if(next=3D=3Dthis) {delete ptr;} else{next->prev=3Dprev;prev=
->next=3Dnext;}}
operator=3D(shareable_auto_ptr<T>&sap ) throw()
{ if(ptr!=3Dsap->ptr) {
if(next=3D=3Dthis) {delete ptr;} else{next->prev=3Dprev;p=
rev->next=3Dnext;}
ptr=3Dsap.ptr;next=3Dsap.next;
prev=3D&sap;sap->next=3Dthis;next->prev=3Dthis;
}}
operator=3D(T*p) throw()
{ if(ptr!=3Dp) {
if(next=3D=3Dthis) {delete ptr;} else{next->prev=3Dprev;p=
rev->next=3Dnext;}
ptr=3Dp;next=3Dthis;prev=3Dthis;
}}
T& operator*() const throw() {return *ptr;}
T *operator->() const throw() {return ptr;};
T *get() const throw() {return ptr;};
bool operator=3D=3D(const shareable_auto_ptr<T>&sap) const throw(=
) {return ptr=3D=3Dsap->ptr;}
private:
shareable_auto_ptr<T> *next,*prev;
T *ptr;
};
this have never compiled!!!!, just an idea!!!
note that the memory overhead is 2 pointer for each pointers used, not
just 1 integer for each object pointed to, and unlike one boolean for eac=
h pointer like auto_ptr !!!
anyway, if it is only designed for containers, they don't have many redun=
dent
copy for a long time...
all operation are constant in time... not bad...
not much worse than auto_ptr...
Further, I've encountered a new concern:
in auto_ptr there is the "release" method that permit to
dischare an auto_ptr to the deletion of the object...
in my proposition I don't know how to implement it
logically...
the first solution is to zero the pointer, yet not delete
the object if necessary... but if this pointer is not the last, another c=
ould trigger the deletion later...
the other solution could be to zero all the pointers sharing the ownershi=
p,
and not delete...
does such action have any sense...
is just a comatibility with auto_ptr not just sufficient...
ie: it work only if I'm the only owner...
else not defined !
or is the broadcast zero more logical ?
or must it be congigurable
with a releaseMyCopy() and a releaseAllCopy()
what are your opinion on all this
(discussion, arguments,code)...
TIA. 8)
--
Alain Coetmeur, Informatique-CDC DTA
mailto:acoetmeur@icdc.CaisseDesDepots.fr
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/15 Raw View
In article <6od5ev$ag0@handupme.avid.com>,
paul@ra.avid.com (Paul Miller) wrote:
> Edward Diener <eddielee@abraxis.com> writes:
>
> >Is it safe to use auto_ptrs in containers ? If not, what are the issues ?
>
> Yes if they are reference-counted.
But they aren't, and the standard explicitly forbids their use in
standard containers.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Edward Diener <eddielee@abraxis.com>
Date: 1998/07/15 Raw View
Thanks to everyone. I read the GotW #25 and understand the issues involved.
Edward Diener wrote:
> Is it safe to use auto_ptrs in containers ? If not, what are the issues ?
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: paul@ra.avid.com (Paul Miller)
Date: 1998/07/13 Raw View
Edward Diener <eddielee@abraxis.com> writes:
>Is it safe to use auto_ptrs in containers ? If not, what are the issues ?
Yes if they are reference-counted. We're using reference-counted
smart pointers all over the place and they work wonderfully well.
I wrote a templated base class with the reference count in it, to be
used as the base for any reference-counted classes. Then there is the
reference-counted smart-pointer which uses the reference count in the
object to keep it alive or kill it when it goes to zero. Factory
methods are used to create the objects.
Surprisingly efficient as well.
--
Paul T. Miller | paul@elastic.avid.com
Principal Engineer | Opinions expressed here are my own.
Avid Technology, Inc. - Graphics and Effects Software Group
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/13 Raw View
Paul Miller wrote:
>
> Edward Diener <eddielee@abraxis.com> writes:
>
> >Is it safe to use auto_ptrs in containers ? If not, what are the issues ?
>
> Yes if they are reference-counted. We're using reference-counted
> smart pointers all over the place and they work wonderfully well.
>
> I wrote a templated base class with the reference count in it, to be
> used as the base for any reference-counted classes. Then there is the
> reference-counted smart-pointer which uses the reference count in the
> object to keep it alive or kill it when it goes to zero. Factory
> methods are used to create the objects.
>
> Surprisingly efficient as well.
The auto_ptr he is referring to is not a generic smart pointer; it is a
specific templated class in the STL, and I believe the proposed standard
requires it to have various features that prevent it from being safe to
use in a container. I can't be sure, because the FDIS is significanlty
different from my copy of CD2 in this area. In any event, auto_ptr's are
unambiguously not required to possess all the features needed for them
to be safe for such use.
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: herbs@cntc.com (Herb Sutter)
Date: 1998/07/14 Raw View
>Edward Diener <eddielee@abraxis.com> writes:
>>Is it safe to use auto_ptrs in containers ? If not, what are the issues ?
No. The fundamental issue is that for auto_ptr copies are not equivalent.
Hence they cannot be safely used in containers (and by algorithms!) which
assume that copies are indeed equivalent.
To make this safer and prevent such misuse up front, the final auto_ptr
was actually designed to be uncompilable as a container template parameter
(i.e., writing "vector< auto_ptr<int> > v;" should not compile).
See also GotW #25 at www.cntc.com/resources for more details.
paul@ra.avid.com (Paul Miller) answered:
>Yes if they are reference-counted.
No, auto_ptr does not use reference-counting. In fact, the standard does
not include any reference-counted pointer.
See also http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
(this newsgroup's FAQ) under question C3: "Why does the standard include
auto_ptr instead of a reference counted ptr?"
Herb
---
Herb Sutter (mailto:herbs@cntc.com)
Current Network Technologies Corp 2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com Mississauga Ontario Canada L5K 2N6
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Edward Diener <eddielee@abraxis.com>
Date: 1998/07/12 Raw View
Is it safe to use auto_ptrs in containers ? If not, what are the issues
?
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: david+usenet@unico.com.au (David Goh)
Date: 1998/07/13 Raw View
In comp.std.c++, on 12 Jul 1998 16:52:27 GMT
Edward Diener <eddielee@abraxis.com> wrote:
> Is it safe to use auto_ptrs in containers ? If not, what are the
> issues ?
The short answer is "No".
The quick answer is, auto_ptr copies are *not* equivalent, and
containers are allowed to presume that they are. As a result, it's
possible to encounter undefined behaviour as a result of putting auto
pointers in containers.
For a more complete answer, see http://www.cntc.com/resources/ and
look for the "Guru Of The Week" posts... and see specifically
"GOTW#25 auto_ptr". Or use dejanews and hunt for "Guru of the Week
#25" in comp.lang.c++.moderated.
Later,
David
--
| david@unico.com.au (David Goh, Unico Computer Systems, +61-3-9866-5688)
I have a theory that it's impossible to prove anything,
but I can't prove it.
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Greg Colvin" <spam@me.not>
Date: 1998/07/13 Raw View
Edward Diener <eddielee@abraxis.com> wrote in article
<35A7E96F.6A9F21D3@abraxis.com>...
> Is it safe to use auto_ptrs in containers?
For the most part no.
>If not, what are the issues?
Any attempt to copy the auto_ptr will leave behind a null pointer,
and standard containers need to copy their elements.
Greg Colvin
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]