Re: The D Programming Language
Andrei Alexandrescu (See Website For Email) wrote:
James Kanze wrote:
Andrei Alexandrescu (See Website For Email) wrote:
I think it's one thing to have a wrong numeric value and one very
different thing to have a program in which all hell breaks looks due to
random overwriting of memory.
But nobody's really disagreeing. Being able to accidentally
randomly overwrite memory is hardly what I would call a feature.
(Being able to do it intentionally, e.g. with a
reinterpret_cast, is a necessary feature if you want to develope
kernel code, but that's a different issue.)
On the other hand, faced with a serious program error (e.g.
inconsistent values resulting from a race condition), having all
hell break loose is certainly preferrable to silently continuing
and pretending that all is well. And issuing a market order to
buy when our customer said sell.
The problem is that the hell could break loose by also issuing a market
order to buy when our customer said sell.
The problem with a program is not that it crashes - that would be great
- but that it can do anything, including not crashing.
I guess the set of "all hell breaks loose" is much larger, and includes,
the set "there is one incorrect value". I am sitting here in amazement I
have so much trouble getting this point across.
Certainly. The only point I'm trying to make (here---there seem
to be multiple issues being discussed in parallel) is that even
with Java's "defined behavior", all hell can break loose. That
both are really "undefined behavior".
Except that we're not really discussing the undefined behavior I
find in Java. I agree that requiring error checking is a good
thing. And that C++ has too much undefined behavior, especially
in a lot of cases where there's absolutely no need for it.
Somehow, the argument has gotten away from my statement that all
languages have some forms of undefined behavior.
And I suspect that despite all of the niggling, you, David and I
would fundamentally agree that the problem in C++, in such
cases, isn't that you might crash, but that you can't count on
crashing. I'd even go further and say that I prefer the Java
solution of consistently doing the wrong thing to that of C++,
which results in inconsistent and untestable behavior.
Undefined behavior is bad, and C++ has far too much of it.
On the other hand, it's impossible to eliminate it entirely;
some of it comes directly from the hardware we run on, and
eliminating other cases (e.g. some of the threading issues)
really does impose unacceptably high run-time costs.
And that some undefined behaviors in C++ are there explicitly to
allow implementors to define them in a way that makes sense on
their platform.
[...]
I'm not sure how such personal anecdotes relate to the undefined
behavior issue, however. I don't think that there's any doubt
that Java has a lot less undefined behavior than C++: you claim
zero, and I claim that there are a very few special cases, where
as C++ has it all over the place.
I am eager to hear about the few special cases, and I have tried to
substantiate my point with what I found on the net. Would somebody
please oblige.
Try dropping the power supply to the CPU chip by 20%, and see
how "defined" the behavior is.:-)
Try doing any multithreaded programming without proper
synchronization, and you'll get unpredictable results. The
language standard doesn't specify what happens globally, even if
it tries to specify most individual accesses. And if what
happens isn't defined, how can you say that it isn't
"undefined".
--
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! ]