auto_ptr and deep copy semantics

Thread View: comp.std.c++

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Avner Ben Mon, 04 Dec 1995 21:08

#2853

Author: Avner Ben
Date: Mon, 04 Dec 1995 21:08

28 lines
2070 bytes

This message was somehow lost in the process of  transfer, so I submit it again:

I find it hard to understand the reason behind template class auto_ptr's (April draft) "strict ownership semantics." Its copy-constructor and assignment operator call __release__ on the source, and thus "effectiviely transfer control" of the pointed object. 
I am dissapointed. I expected auto_ptr or a simmilar variety to feature __deep-copy-semantics__. Of-course, this variiety is more restrictive - it requires the template paramter to have copy-constructor, assignment operator and destructor. The obvious use for deep_copy_auto_ptr is to simplify the maintainance of containers of pointers to objects. The STL makes life hard when you embed, in a class, a member that is a template instantiation of a container on pointer type. You must write you own ccotr, assignment operator and destructor for the enclosing class, to ensure the deep-copy semantics. You are excempt from it, when you embed a container that stores objects by value. Writing one's own deep_copy_auto_ptr template solves the problem. I am surprised to find that this simple facility is not part of the language! (Or I may be wrong in my whole endestanding of STL usage).

	Avner Ben | avnerben@netvision.net.il



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

Re: auto_ptr and deep copy semantics

#2957

Author: Martin Prange
Date: Wed, 20 Dec 1995 18:36

67 lines
3088 bytes

Distribution:

In article <4ahrti$2i3@oznet03.ozemail.com.au> John Max Skaller <maxtal@suphys.physics.su.oz.au> writes:

>From: John Max Skaller <maxtal@suphys.physics.su.oz.au>

[deleted...]

>  I have a SET of reference counting pointer classes under development
>for public release (email for beta test): the problem is not so simple. 
>(Coplien wrote a book on it :-)
>
>  I currently provide or plan [names yet to be fixed!]: 
>
>  AutoPtr         (NOT copyable!! not actually ref counted)
>  InvasivePtr     (Kanze technique, invasive)
>  InvasiveBasePtr (Manual copy by cloning)
>  InvasiveLeafPtr (Manual copy by ctor)
>  Ptr             (Colvin technique, non-invasive)
>  BasePtr         (Manual copy by cloning)
>  LeafPtr         (Manual copy by ctor) 
>  ValueRep        (Unconditional copy by ctor)
>  ObjectRep       (Unconditional copy by cloning)
>  COWValueRep     (Copy by ctor on non-const access)
>  COWObjectRep    (Copy by cloning on non-const access)
>  RefMem          (Ref counted raw memory)
>
>and I suspect <grin> the list is not yet exhausted -- possibly
>instrumented and non-instrumented versions make sense
>for example. The set may become more compact with
>availability of better C++ compilers (that don't
>instantiate unused members :-(
>
>Have I missed any cases (probably!!)

Sure you did.

There is a set of specialised Links with all of these properties 
attached ( and more ...) described in the (old, IMHO ) PCTE standard.

I'd give you some web sites to browse, but ....
have a look at lycos searching for "PCTE" :

   2) PCTE directory [0.9019]
 
   Abstract: PCTE Up to pub * ECMA_PCTE * ECMA_TGEP * ECMA_TGRM * ISO_PCTE *
   ls-lR * NAPI * NAPUG * PCTE94 * PCTE_OO+FG * PCTE_papers * PCTE_products
   * PCTE
   ftp://omg.org/pub/PCTE (1k)
 

--
 Martin Prange / Member of ALMAP Team / ALCATEL +49 30 7002 3120 
 just alcanet: prange@bln.sel.alcatel.de else @cs.tu-berlin.de
 If you believe, the opinions expressed here are mine - you got it


[Moderator's note: This discussion is beginning to move away from C++
standardization and towards C++ programming.  Any responses that deal
primarily with types of reference-counted pointer classes and how to
write them should probably go to comp.lang.c++.moderated instead of
to comp.std.c++.  mha]

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads