Re: The D Programming Language
Peter Dimov wrote:
Andrei Alexandrescu (See Website For Email) wrote:
David Abrahams wrote:
"Andrei Alexandrescu (See Website For Email)"
[...]
So my answer to "Purify can't tell you..." is "Because you don't
need Purify".
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.
Dave's point, to which I also subscribe, is that when nothing in a
programming language is illegal, you have no "legal standing" to
declare a program incorrect. So you can't have a tool like Purify that
automatically identifies that a program has performed an illegal
operation, because there are no illegal operations whatsoever.
That makes of course sense; the logic is iron-strong. Yet I can't see
how that is an advantage for languages that allow illegal operations. On
the contrary.
It is certainly true that illegal operations that manifest themselves
as changing valid object memory at a random location are an incredible
pain to debug. On a practical level, this cannot be denied. On a
theoretical level, there is nothing in the C++ specification that
mandates that undefined behavior must be left undetected; in principle,
this allows a C++ implementation to be safer than Java. (In practice,
this never happens, because there is (was?) no market demand for it.
Hardware architectures that dutifully crashed your program on every
invalid pointer operation are now extinct.)
Of course there's no market demand for it. Such architectures or
compilers would slow down the program to a crawl. The C machine model
does not allow program operations to be easily checked.
Imagining and building checked execution is very easy for all languages.
The art is in finding a machine model that allows efficient execution
and programmer freedom by choosing the exact "right" restrictions. That
is very hard, and appreciating the results is a subjective process. Of
all languages I've heard of, ML got closest to that ideal.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]