Re: The D Programming Language
David Abrahams wrote:
Jean-Marc Bourguet <jm@bourguet.org> writes:
"Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEmail@erdani.org> writes:
Well the only thing I can add is that in my limited experience,
debugging Java programs is much easier because there's never the case
that a dangling pointer misteriously overwrites some object it wasn't
supposed to.
Instead you are writing to an object which was supposed to be out of
existence for a long time. In my experience, that give you the same kind
of elusive bugs. Excepted that purify can't help you
I want to emphasize that point: when nothing is truly illegal (like
those things that C++ says cause undefined behavior), there's no way a
tool like Purify can tell you that the program did something wrong.
But in a memory-safe program you don't even need Purify to tell you that
the program did something wrong. A logging module would suffice, and the
proof is in the trace.
The important tidbit that makes it all work is that bugs anywhere in the
program can't mess the logging subsystem.
Let's face it. Memory safety is too nice a property. If the argument is
that it leads to messier languages and slower programs, I'd agree. But
IMHO the arguments brought in this thread didn't carry much weight.
So my answer to "Purify can't tell you..." is "Because you don't need
Purify".
and that random behaviour including crashes are replaced by
deterministic, often plausible but wrong results.
Of course that can happen in a system with undefined behavior, too.
That said, it looks like a wash to me: incorrect programs have
different characteristics under the two systems but neither one wins
in terms of debuggability.
The memory-safe program wins because it never overwrites arbitrary
memory; so all objects unaffected by a bug respect their invariants.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]