Re: Silver bullet for C++ memory management ?
peter koch <peter.koch.larsen@gmail.com> writes:
On 26 Mar., 02:49, (...) Stefan Ram wrote:
In Java, one can not have objects on the stack,
In C++, one also can not have objects on the ?stack? (ISO/IEC
14882:2003(E) does not mention a ?stack? in this sense). Of
course, a stack is a feature of many C++ /implementations/
(not of the language [except for the class template
?::std::stack?]).
On the other hand, I now remember, that some Java
implementations have or a going to have ?escape analysis? for
the lifetime of an object: If the implementation can prove
that the object's lifetime will not escape a method
incarnation, it then /will/ be placed on the stack (into this
method's stack frame) - also an implementation feature.
So in Java one /can/ have objects on the stack in a similar
sense as in C++ (in C++, one possibly can have more objects on
the stack).
The above is a clear indication that one of two conditions were
present:
a) The code was not critical, so the programmers did not care about
performance.
b) The programmers was incompetent.
There are shades of gray between ?competent? and
?incompetent?.
Were the programmers and managers involved in the Mars Climate
Orbiter loss due to a mixture of pounds and kilograms in 1999
?incompetent??
There are languages, where less competent programmers will
more often get more correct results. Where they cannot make
certain mistakes and have to do less bookkeeping, which frees
mental resources for other realms.
In practice, Java will be 2-3 times slower than the same
program written in C++ or a comparable language - e.g. Ada.
I believe, in the average, this should be approximately true.
And yet Java imposes a OO paradigm.
Java is neither fully nor purely object-oriented, but, yes,
it supports run-time polymorphism, but not the template
instantiation at compile time as in C++.
(But some Java implementations have just-in-time compilation,
which partially can make up for this, although this is
does not address the same abstractions/instantiations.)
Memory management has never been a major problem.
When one is starting to build a graph to keep track of
relations and nodes, and parts of the graph can be deleted
from this graph at run-time, one needs to check whether after
a removal of a part of the graph there are new disconnected
(unreachable parts) of the graph; they, too, need to be
disposed, then. To find them, one needs to implement some kind
of garbage collector, if the programming language does not
already have one.
In other cases, one might get by with certain rules about
memory ownership and its transfer.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]