Re: Garbage Collection - The Trash Begins To Pile Up
Le Chaud Lapin wrote:
Dave Harris wrote:
GC is irrelevant here; we were talking about whether RAII was a 100%
solution (having conceded that GC isn't). If we agree that RAII is not
100% either, it becomes unfair to reject GC for that reason.
So neither is 100% the solution. Accepting this fact, the question
then becomes:
In a well-designed system to what extent is the Yin/Yang-RAII model
applicable and to what extent is the GC model applicable. The essence
of what I have said is that the percentage Y, of Yin/Yang classes, to
total number of classes, is closer to 1 than 0. The percentage G of
GC-type classes is closer to 0 than 1.
Does it matter? The percentages will obviously depend on the
application; I've worked on applications where there was no
dynamic memory used at all.
For applications which make extensive use of dynamic memory,
garbage collection is more robust; it allows dynamic detection
of dangling pointers at run-time, without an external framework
like Purify. Most commercial and industrial applications use
dynamic memory, since most such applications have objects whose
lifetime is not linked to scope. So using garbage collection
for such systems increases their robustness.
Many applications will also use values whose size cannot be
predetermined; text strings are an obvious example. For such
value objects, garbage collection is a definite win.
Y = (# of Yin/Yang classes) / (total # of classes)
G = (# of GC classes) / (total # of classes)
In my system, Y is perhaps 172/180, so that is about 95.5%
G would then be about 4.5%.
What we are claiming is that we believe our situations are not unique.
They don't correspond to anything I've seen in the industry.
They certainly don't correspond to GUI oriented clients, nor to
large scale servers. They may correspond to some critical real
time applications, where dynamic memory is not appropriate, but
that still leaves a lot of other applications.
We do not believe that our systems are inherently solvable using
Yin/Yang classes anymore than they are inherently solvable to GC
classes. We believe that the _programmer_ *chooses* one model.
Why? Every place I've worked, we've used a variety of models,
according to the exact problem to be solved. The programmer
chooses a model in each individual case. There is no one size
fits all here---no silver bullet.
We
also feel that, perhaps out of habit, a given programmer is predisposed
to choose one model over the other, even before knowing what the design
entails.
That's an awfully poor programmer. I've known one or two like
that, but they're certainly not the majority.
We also believe that, given that two different
predispositions will undoubtedly yield two different forms, one of
these forms is bound to be more reliable, easier to modify, less
complex, more predictable, etc.
We *think* our form will be the one that is easier. But the only way
one can know this is to have experience with both, enough to develop a
visceral intuition about which is better.
I've considerable experience with both (supposing that by
yin/yan, you mean RAII). Sometimes, one is more appropriate,
sometimes another.
Finally, we do have the guideline from Bjarne Stroustrup that, all
things being equal, we should try to make Y closer to 1 than 0.
Where? This is news to me; he certainly seemed favorable to
garbage collection in the committee meetings.
One way to explore both models is to take some real design problems,
present them here, and put up descriptive solutions and let the general
community analyze the pro's and con's of each.
Real design problems have solutions which run in the millions of
lines of code. I don't think it realistic to post them here.
And I (and others) have consistently posted specific cases where
garbage collection provides a better solution. You just choose
to ignore them, since your "silver bullet" doesn't ofter as good
a solution.
[snippage]
Sometimes the operating system gives you a window handle and you need to
create a C++ object to encapsulate it. That's just the way some
operating
systems work. For example, the window handle which represent the desktop
exists before your application even starts up, and will continue to
exist
after your application shuts down. Obviously you can hide the details
with
a library and abstraction layer, but they are still there.
Yes, Window handles are special under Microsoft Windows. They are
widely regarded as the one situation where you should not try to apply
RAII because the people who made the handles made them in such a way
that they resist RAII. Many a programmer has fallen into the trap of
trying to model them as such.
Synchronization objects like mutexes, events, etc.. OTOH .....;)
Synchronization objects like mutexes rarely have local scope,
and can't generally be handled using RAII. In many cases, they
exist for the lifetime of the program; in others, they are
associated with entity objects, with deterministic lifetime.
The place where RAII is useful here is for the locks on such
objects.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, 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! ]