Avner Ben <avnerben@netvision.net.il> wrote:
>I am dissapointed. I expected auto_ptr or a simmilar variety to feature
>__deep-copy-semantics__.

  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!!)
--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



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

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

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.=20
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. ]