Re: Garbage Collection - The Trash Begins To Pile Up

Nevin :-] Liber wrote:


Finally we get to the fundamental issue. :) I believe they are not,
but should be.

Like Mirek Fidler, I rely heavily on the "automatic" features of C++.
These are:

1. Put operator new() in the constructor
2. Put operator delete() in the destructor
3. Never use a polymorphic object when a monomorphic object will do.
4. Never new() an automatic object just for the hell of it. That's
what auto is for.
5. If a massive structure is required, built it using containers.
Containers are lovely.

I will give you a concrete example:

In one of my EXE's, I have a data structure which you would call a
multi-rooted tree. The tree is associative, so I can look up a
node-pair in the tree based on List<> of elements. The elements in the
list successively help to locate the pair based on the left-hand
element of each pair. The type of the LHE of a pair is the same as
the type of an element of the List<>. The structure is templated so
that all types are polymorphic at compile time. In my current system,
the RHE of a node in the tree is itself a *massive* data structure
containing no less than 4 associative sets, 2 associative list, a
hybrid structure that is essentially a List<String,
Red_Black::Associative_Set<String, List<String> ...."'. This RHE also
contains Integers that can be 400 digits long, as well as primitives
for cryptography, time-related objects, etc.

If someone were to ask me if this massive thing would ever leak memory,
I'd say "no" before they could finish the sentence. How do I know? I
know because the system has been structure in a way that memory leakage
is impossible. The worst that can happen is an exception could be
thrown for lack of memory for call to new().

But that's not the fun part. What makes this fun is that this massive
structure is one of more than 25, in the same program, with up to 30
hreads at once, all with locking and unlocking on structures, seeking
to various elements, doing database I/O as well as over network I/O.
There are maybe 225 .cpp files , and the number of lines of code that
contains a new() or a delete is less than 15, probably more like 10.
What is nice about this situation is that the few times that I *do* use
new() or delete, I know with certainty that the nature of the data
structure being modeled is such that it absolutely, positively,
warrants a polymorphic object. So I have no problems with it, and I
can easily eyeball the situation and say again.."This system will not
leak memory. Ever."

This is where we differ. Some people got it in their head that, since
it is hard to "find the classes", they might as well go for broke and
make everything a giant new/delete/polymorphic slop party. They take a
moderately complex data structure that could have easily been
monomorphic and make it polymorphic...and deal with the consequences.

-Le Chaud Lapin-

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]