Re: C++ Speed Vs. Java
Keith H Duggar wrote:
James Kanze wrote:
[...]
In my business, furnishing wrong information, or failing
to furnish complete information, is considered worse than
a core dump. You know, the sort of thing that happens
when you get a NullPointerException in the middle of
Swing.
Completely agreed. Based on a previous post of yours I think
we are in the same business at the moment. And yes, in that
business a core (preferably as soon as possible) is much
better than, for example, sweeping the book due to a bad
price. Especially when you are setup to simply and easily
roll back to a previous stable version of the program.
Note that this is true for a lot of application domains.
Realistically, all applications must be able to live with a core
dump, because realistically, there's no way to guarantee 100%
that you won't get one. Critical applications must have some
sort of backup system, and triggering a core dump is often the
fastest way of triggering the back-up system to take over.
Hmm ... this makes we wonder about bald pointers. Recently,
the use of bald pointers in some older code was actually
beneficial in a way. When an obscure and rare error caused
them to dangle, subsequent access rapidly cored allowing us
to detect and eliminate the problem.
The problem with such things is not that a dangling pointer
might core dump, but that such a core dump is not guaranteed.
It could also result in simply changing some data elsewhere.
Had the authors used a
naive shared pointer the stale objects would have stayed
around supplying bad data for the life of the program.
Reproduceably supplying bad data:-).
This is, IMHO, one of the advantages of using classes instead of
simple structs. The stale object can set a flag, which it tests
when asked for the data. (If the test is in the form of an
assert, you've get the core dump, as above. But guaranteed.)
Of course, a shared_ptr/weak_ptr idiom would probably have
been a good option. But, this makes we wonder about the Java
everything is a (naive) reference and we'll handle lifetime
for you.
That's a misconception concerning Java (admittedly brought on by
some of the Java advocacy literature). Java does nothing to
handle object lifetime. (What it does do, of course, is allow
you to write code to detect lifetime errors, and be sure it
works. But you get this in C++ too, at least if you're using
the Boehm collector to handle memory management, so that you are
sure that the memory won't be recycled until there are no more
pointers to it.)
Unless you explicitly code an acquire/release idiom
(which is a bit of a pain without deterministic destructors)
then such stale object errors can easily go unnoticed for a
very long time.
Acquire/release doesn't have to be associated with destructors.
Associating it with destructors is really only an advantage when
objects have lifetimes known to the compiler, so the compiler
can implicitly call the destructor at the right time. Once the
object has been allocated dynamically, it's up to the
programmer, and it doesn't really matter whether you use
destructors (with a special syntax, e.g. delete, to call them),
or whether you use some other named function. (The problem with
Java here, of course, is that there are no objects for which the
compiler knows the lifetime.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
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! ]