🚀 go-pugleaf

G. Bowden Wise writes:

|> J. Kanze wrote:

|> > I use reference counted pointers a lot, but they have their own set of
|> > problems.  I can very well understand the committees reluctance to 
|> > adapt them.

|> Can you share with us the problems with reference counter pointers?
|> How do those problems compare with the auto_ptr problems?  Perhaps
|> we need some kind of hybrid between the two.

The problems are not so much with use, but with how to standardize.

There are two distinct approaches with regards to reference counted
pointers: invasive and non-invasive.

Invasive reference counting involves significant constraints with
regards to the counted objects.  None of the basic types meet these
constraints, nor can they be made to.  None of the other types in the
library meet them, either.  In this case, the committee could eventual
change this, but in many cases (iterators, for example), meeting the
constraints would involve significant overhead, which would then be
paid by everyone, including those who didn't use reference counting.
(For a good discussion of invasive reference counting, see Scott
Meyers' new book.)

Non-invasive reference counting has significant run time overhead.  In
fact, the overhead is enough to make invasive reference counting the
prefered method in most cases (IMHO).  (For an example of non-invasive
reference counting, see Barton and Nackman.)  My experience suggests
that in most cases where reference counting is appropriate, I am
implementing reference semantics for polymorphic objects.  In these
cases, the invasive approach is definitly to be prefered.  I suspect
that if the standard had adapted a non-invasive approach, I probably
would not have used it anyway.  (My own reference counted pointers
require the referenced object to inherit from GB_RefCntObj.)

Another potential problem: reference counted pointers do not work when
there are cycles in the reference chain.  As such, there actual field
of use is much more restricted than one would like (for something in
the standard); I use them because most of my objects fall into
hierarchial structures, which forbid cycles.  But for many application
domains, the restriction that the references not contain cycles is
non-trivial.  I can imagine that some people would oppose their
presence in the standard on the grounds that we do not want to
standardize something that is so intrinsically dangerous; it might
give people a false sense of security.  (By the same logic, of course,
we should eliminate gets, and even sprintf, from the standard.
History rules, however.)

In view of these two problems, I myself do not see a real role for
reference counted pointers in the standard.  Note that neither of
these problems affect auto_ptr.  (In theory, I guess, you could create
a cycle with auto_ptr, but I cannot really imagine the case occuring
in real code.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]