"Boehm, Hans" wrote:
> What happens if the object goes away in response to an assignment, in spite
> of the fact that I still have an auto pointer to it?

    You can only get an auto pointer from a const smart pointer.
This, I admit, is painful.  I need to write some code in this style
and see how it goes.
> >
> > Once a strong reference count goes to 0, there's nothing the
> > destructor, or anything else, can do that will increment it again.
> > We thus avoid the "resurrection" problem, can't generate
> > dangling pointers in a destructor, and get clean
> > destructor semantics.
> I actually don't think resurrection is a problem.  The Java semantics are
> clean in this respect.  The collector code naturally does the right thing.
> I would have added a "reenableFinalization" call to the API, but that's a
> minor issue.

      I'm thinking of Microsoft Managed Objects for C++, which
provides for destructors, finalizers, resurrection, and several
states of near-death.  This is the biggest attempt so far to
support GC, destructors, and finalizers all at once within C++.
One might suspect that the real intent is to drive programmers
toward using C#.

> Have you looked at the paper by David Bacon et al in the last PLDI?  The
> claim to handle cycles correctly and promptly.  And I suspect this part of
> their algorithm is independet of their decision to handle reference count
> operations in a separate thread.  The worst-case cost is not good, but they
> claim, the typical cost is quite reasonable.

      That's neat.  But it does require a collector that knows
object structure.  That's a tough retrofit for C++.  It might
be a good choice for a C# implementation.  Or, for that matter,
Perl.  (It's off-topic, but somebody should look into putting that
algorithm into mod_perl for the Apache web server.)

      I have to admit that, after working on safe smart pointers for
a while, it's become clear that it's possible, but not clear that
it's tolerable.

      On a related note, there's interest in using the "auto" keyword
for implicit typing.  How about using "new" for that instead?  As in

 new p = foo;

Since "new" isn't meaningful as a left hand side, this is unambiguous.
And "new" seems linguistically appropriate.
This is better than using auto, since using auto for that purpose
would lead to constructions like

 static auto p = foo;

which seems wierd.

      John Nagle
      Animats

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]