Re: calling a pure virtual from base constructor
lancediduck@nyc.rr.com wrote:
Denise Kleingeist wrote:
facilities to automatically handle much more expensive
resources like files, locks, database connections, etc. ...
and, judging from the frequently observed memory consumption
of applications built using the languages, they are not even
good at it!
Java uses either mark-sweep or copy-collection memory
management techniques, and in some virtual machines,
mark-sweep is employed at first, and then the latter takes
over as the application resources stabilize. In either
strategy, the idea is to NOT release ANY memory back to the OS
(or other heap manager) until ALL available memory has been
exhausted. This is by design, and considering the
ubiquitousness iof Java (and other languages that use the same
strategies) really not a problem.
I don't think the problem is garbage collection per se; I
regularly use the Boehm collector with C++ programs, and there
are no problems with it. The problem is careless coding in
general, which results in leaking memory; basically, at least
when I used it, many of the Java Swing base classes held on to
pointers to memory that wasn't used any more. (The original
Java Swing interface was designed to encourage this.) And if
there's a pointer to the object, garbage collection won't
collect it, even if the object is never used again.
Garbage collection, used correctly, is a useful tool, which
saves the programmer some work (and thus, saves his employer
some money). It's not a panacea or a silver bullet, however,
and it won't turn a bad program into a good one.
In reality, it turns out that there was (or indeed is) a
prejudice in language design towards being able to have cycles
when using resource management. C++ of course, for the reasons
you mentioned, and not the least which is to support the
fundamental C++ idiom (RAII) cannot have an object or resource
manager that tolerate cycles.
Sure it can. In practice, in any reasonable application, there
will be cycles.
For resources other than memory, regardless of the language, you
have to break them somehow. Often, not just to ensure proper
release: cycles in mutex lock aquisition can rapidly lead to
deadlock conditions, for example.
In general, regardless of the language, you have to do some
design before you start writing code.
And it turns out, as you indicate, that resources OTHER than
memory cannot tolerate cycles either... This is why the
recent smart pointer voted in the C++ standard TR1
report(section 2.2) includes weak pointers, and only support
reference counting strategies.
Besides, in order to support mark sweep or copy collection or
other cycle allowing strategies, a language must also support
"roots" which mean that things created as statics or on the
stack are "different" than heap objects.
Not at all. C++ supports garbage collection, and it certainly
does nothing like this.
There are restrictions as to what kinds of garbage collection
can be used with C++, but they come more from the aliasing rules
(unions, pointer casts, etc.) than from any lack of a
distinction between staticly and dynamically allocated objects.
There's also the fact that in all of the cases I know, the
garbage collector is a third party add-on, and the compiler
doesn't collaborate, so the garbage collector has a lot less
information to start with.
In C++ they are all the same (in terms of the object model)--
this makes any sort of cyclic resource management inpractical.
(No it is not obvious at first why this is so-- I'll leave it
as a exercise to the reader to convince themselves)
I'm not quite sure what you're trying to say, but in practice,
garbage collection is widely used in C++, and it works in most
applications. And the garbage collectors being used have no
problems with cycles.
Java (And C#) and C++ have very different approaches toward
resource management and object lifetimes.
All too often, Java ignores it. With sometimes disasterous
results---closing a Window in Swing used to leak a couple of
Megabytes each time. This has been at least partially resolved
by the use of weak references. In the particular case of Swing,
I'd categorize this as a hack to work around a design flaw.
(Note that I think that globally, Swing is very well designed.
But even well designed systems occasionally have flaws.)
Note that the problem here isn't so much one of program design:
you can manage resources correctly in any language, if you
decide to do it. The problem is one of programmer attitude: the
idea that you can write a correct program without doing any
proper design. (One frequently heard myth today is that an
extensive test suite can replace design.)
One problem that Java has had (and that C++ had before it) is
that it is an "in" language. Which means it attracts all of
those who are better at bullshitting than at programming. The
result is a lot of bad programs written in Java. Probably the
best thing that happened to Java, in this regard, is C#; as C#
becomes the "in" language, the bullshitters will abandon Java
for it, and the overall quality of Java programs will shoot up.
I would not consider one broken over the other -- indeed one
could easily consider that "return value lifetime" is broken
in C++ (danging reference anyone??) but Java handles this
nicely.
Sort of. If the lifetime of the object has finished, just
keeping its memory doesn't help much. For things like string,
which have no inherent lifetime, the Java model means less work
for the programmer. (Except, of course, that you can use the
Boehm collector and do the same thing in C++.) For things that
have inherent lifetime, you can still have dangling pointers in
Java.
--
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! ]