Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (              Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: oo definition request
Message-ID: <6590052@hplsla.HP.COM>
Date: 16 May 88 18:57:50 GMT
References: <4800021@uiucdcsm>
Organization: HP Lake Stevens, WA
Lines: 26

|    5) and, automatic storage management
|       - better know as garbage collection
|       - should qualify as fifth important element

Garbage collection seems to conflict with the needs of many "real-time"
programs.  So if one took "garbage collection" as a requirement
for OOP, then you'd be excluding OOP from many "real-time" applications.
So I don't buy item #5.

Maybe #5 could be rephased more generally as:

5) and, concepts for storage management.

Then C++ would still qualify [and should qualify, I believe, because I
believe C++ gives you the tools necessary to do a good job of storage
management]

Maybe "garbage collection" could be handled as a standard C++ "base-class"
that interested users could inherit off of, without the whole C++ community
having to buy into this overhead.  Still, I have a hard time believing that
a large portion of the C++ community could agree on one common approach
to garbage collection that would meet all their needs.  Which would
counter-indicate even a standard "garbage collected" class.

So far, any project that I have seen that makes extensive use of garbage
collection "everywhere" runs slow enough to be of marginal utility.