Re: If GC is the solution, then what is the problem?
loufoque wrote:
kanze wrote :
Why would we have to distinguish without GC ?
So we can use the object correctly. You can't just
arbitrarily substitute an object of one type for an object
of another, and expect the code to work. (That's why, for
example, C++ doesn't derive everything from a single Object
class. Or why functions are not virtual by default.)
While I have to set apart polymorph and non-polymorph objects,
I do not have to set apart objects with trivial and
non-trivial destructors, which can be more or less difficult
to do in some domains.
Yes and no. (And I agree that the answer may depend on the
domain. I can only speak for the domains I know.) You also
have to set appart objects which must be allocated dynamically,
and those which can also be static or local (garbage collection
frees you from this), and objects which require timely release
(e.g. things like scoped_lock), and objects for which you can
drag your feet more or less.
As I said, I can only speak for the types of applications I've
worked on. In those, all of the dynamically allocated objects
requiring destructors for other than memory management have
either been entity objects, with explicit lifetimes, or have
been owned by entity objects, and had base classes which
explicitly or implicitly expressed this need, so the destructor
of the entity object would have known to handle it.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]