Re: Garbage Collection - The Trash Begins To Pile Up
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.
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.
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. 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. 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.
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.
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.
[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 .....;)
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]