Re: following up on speed

[Mike Salib <address@hidden>]

On Sun, 2002-07-21 at 23:39, Daniel Weinreb wrote:
> >Are you saying that the STL obviates the need for GC? 
> >
> No, certainly not.
> 


I think that the STL does limit the need for GC. STL data structures
often include a small constant size area that references larger
dynamically allocated blocks on the heap. For example, programmers will
typically allocate vector objects on the stack since the vector object
itself is only a few bytes (although it can include pointers to vast
tracts of heap allocated memory). A vector is small enough that you can
toss it on the stack or pass it by value without much thought. When the
vector goes out of scope (i.e., when the block in which it was allocated
is exited from), the vector's destructor is called which happily frees
all the dynamically allocated memory in which data is actually stored.

Its probably not as elegant as GC, but it involves a lot less work than
a good GC. On the other hand, this is a relatively simple case and
doesn't seem to help much when multiple parties need to share an object:
I have a copy, you have a copy, but how do I inform you when I delete
the vector (and you're now stuck holding a vector that points to freed
memory)? Or I have a reference, you have a reference, but who is
responsible for deleting the damn thing? You can deal with this using
ref counting, but ask the python people how well that works. Sooner or
later you get bitten by nontrivial cycles and end up implementing GC...

Hmmm, the more things change...

Didn't phil greenspun say something about how every large C/C++ app
includes a poorly specified, slow, bug ridden version of half of common
lisp?

More info is available at
http://sleibowitz.home.att.net/CPP_Java/AGC.html

Of course I'm not a C++ person, so take what I say here with a grain of
salt (and lemon juice...maybe some balsamic vinegar...perhaps a yogurt
marinade...ok, i'm going to eat now ;-)

regards,
Mike Salib