Re: The D Programming Language
"Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEmail@erdani.org> writes:
David Abrahams wrote:
"Andrei Alexandrescu (See Website For Email)"
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.
a. I don't see how the logging module can do that
b. Anyway, that's often far too late to actually debug the problem.
Am I not getting a joke? Logs are the _best_ way to debug a program.
Are you really telling me that regardless of the type of program, the
best way to debug is always by using a log? What if the log didn't
capture the information you needed?
Of course not. That's a cute comeback but misses the point entirely.
In a GC'd system Purify is the wrong tool because there are no invalid
pointers. Instead you need a tool that tells you that something has
been kept alive too long, and nobody's figured out a tool to do that
because it's effectively impossible for a tool to tell what "too long"
is.
Ehm. I thought we were talking about arbitrary memory overwrites. Maybe
I did miss the point entirely.
I guess so. We were talking more generally about using a pointer to
an object that another part of your program thought it had torn down
or caused to disappear. In C++ that translates into arbitrary memory
overwrites which can sometimes be detected by the OS or an external
tool; in Java that translates into the use of a zombie object, which
can never be detected except maybe by the addition of handwritten
asserts to your code.
The memory-safe program wins because it never overwrites arbitrary
memory; so all objects unaffected by a bug respect their invariants.
The same is trivially true of C++: all objects unaffected by a bug
respect their invariants.
This is wrong.
How can it possibly be wrong?
A memory bug in C++ can affect any object.
Sure.
You could say, yeah, all objects unaffected by a bug have no
problem.
Yeah, I do say that.
The problem is, you can't define the set of objects unaffected by a
bug :o). Right back atcha.
That doesn't make my statement wrong. Your original claim was
tautological. If you want to make this other claim, great, let's work
with that one.
I understand that if you believe certain "sealed" subsystems (like a
logging module) are themselves bug-free then you don't need to look at
them for the cause of your bug... but then you wouldn't look to such a
system in a C++ program either, even if it *can* get stomped by
erroneous code.
I guess I just don't see any black-and-white difference here. Can you
help me understand how this advantage plays out in practice?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]