Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!van-bc!ubc-cs!alberta!cpsc.ucalgary.ca!news
From: gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter)
Newsgroups: comp.lang.c++
Subject: Re: Smart Pointers -- A proposed language extension
Keywords: smart pointers, garbage collection
Message-ID: <1991Jan18.230221.707@cpsc.ucalgary.ca>
Date: 18 Jan 91 23:02:21 GMT
References: <1990Dec28.203554.21028@clear.com> <1991Jan6.072110.27136@cpsc.ucalgary.ca> <1991Jan16.224703.7647@xanadu.com> <1991Jan18.014050.27108@cpsc.ucalgary.ca> <6253@exodus.Eng.Sun.COM>
Sender: gintera@cpsc.ucalgary.ca (Andrew Ginter)
Organization: U. of Calgary Computer Science
Lines: 39
Nntp-Posting-Host: fsd

Chase: If you re-examine Chase's example, you'll notice that it calls
Chase: a function "f" in the middle of that loop.  I thought it was clear
Chase: what "f" might do.

My apologies - I missed "f".  I still argue that the example is
misleading though.  The C code declares "a", "b", and "c" to be smart
pointers, but never executes constructors or other gc registration
procedures on them.  On the other hand, the point isn't worth arguing,
since the example I gave is one where dumb pointer temporaries bite
you even though all possible registration procedures have been called, 
given the current state of the language.

I agree with your points about preemptively scheduled multi-threaded
applications and signal handlers.

Chase: I think a better answer would be to blow off this goal of portability
Chase: in standard C++, and instead get some compiler support or use a
Chase: language that already supports garbage collection.  IF you get garbage
Chase: collection, it's a different language, anyway.  Compiler support for
Chase: garbage collection is a massive win as far as efficiency goes, and you
Chase: don't have to screw around (as Edelson did) with different types for
Chase: references from different locations (Local_Type, Global_Type,
Chase: Heap_Type).  It works, but it is tedious.

That's just it.  Right now, C++ supports reasonably portable
conservative collectors.  Right now, the C++ language does NOT
guarantee the operation of a type safe, reliable, portable,
cooperative collector.  The flaws I've pointed out affect ALL general
purpose cooperative collectors for "standard" C++.  Language support
for cooperative collectors is at least one intended application of all
of the various smart pointer proposals that have come by.  The
question is, can it be done while changing the rest of the language
very little?  Can it be done without sacrificing compatibility with C
source and object code?  Can the result be competitive with manual
allocation?  With conservative collectors?  Can it be done for
parallel applications and applications with signal handlers that may
trigger collections?

Andrew Ginter, 403-220-6320, gintera@cpsc.ucalgary.ca