> Once again, this doesn't follow. You can plug the Boehm collector into C++
> and yet have destructors. What you cannot have is deterministic
> destruction for garbage collected *objects*, since, by design, garbage
> collection is non-deterministic from the perspective of the collector's
> user. However, the presence of a garbage collector does not mean all
> objects have to be garbage collected. This is only the case with Java, the
> designers of which decided to do away with automatic objects. In
> principle, there is no technical reasaon against garbage-collected and
> automatic objects existing side-by-side.
Of course it is technically possible to create a GC and let it manage
memory. There is nothing to prevent you. Admitted, I base my statement on
the fact that a GC in a C++ software system is not a commonly used idiom.
The common case is to use deterministic destruction an dtors.
Notice, also it is well possible to use manual memory management in Java
code. Some people even tought operating systems classes in Java. Anyways, I
claim the presence of a GC in its current widely used form implies some form
of manual resource management for closing files and such. Same would be true
for letting a simple Boehm GC manage a file object in C++.
Anyways, this got way beyond my intention to give reasoning why there is no
try-finally build into the C++ language. Also, I certainly agree GCs make
life easier for business objects consisting of some memory with some data in
it. Dtors are better when a type focusses on resource management, i.e. RAII.
Here, we could add C#'s using statements to the soup...
To those who are interested in the topic of GCs there is an interesting
PodCast available at Software Engineering Radio which I found quite
inspiring since it highlight some technological aspects and limitations:
http://www.se-radio.net/podcast/2007-09/episode-68-dan-grossman-garbage-coll
ection-and-transactional-memory
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Exception specifications unfortunate, and what about their future?
