Re: The D Programming Language
AJ wrote:
Frederick Gotham wrote:
Walter Bright:
I agree with the need for getting rid of undefined behavior as much as
possible, but in a systems oriented language it's hard to see how it can
be gotten rid of completely.
My opinion is the total opposite: Leave behaviour as undefined all over the
place giving plenty of freedom to the implementation.
My knowledge of C++ compiler internals is not very extensive. However, I
still find this "wild-west" mentality kind of detrimental for the end-user.
Very. There are a lot of cases where the undefined behavior
really isn't necessary. Java doesn't allow any freedom
whatsoever with regards to order of initialization, for example,
and yet Java regularly beats C++ in terms of speed when dealing
strictly with basic types.
Can someone with a C++ implementation background actually confirm that
the great hassle that is UB significantly benefits the implementation?
Well, if multithreading is taken into account... The current
C++ standard doesn't address the issue, but I would expect that
modifying a variable from two different threads will be
undefined behavior. Giving it a defined meaning would almost
mean putting a lock around each access, which is really not
acceptable, and for the compiler to detect which variables
cannot be accessed from more than one thread at a time is far
beyond any known compiler technology today.
Not the implementation, of course, but as Walter has pointed
out, there are also cases where the purpose of undefined
behavior is to let the implementation define something sensible
for the environment where it runs. You couldn't do memory
mapped IO, for example, without exploiting undefined behavior
that the implementation has "defined".
That is to say, that the benefit outweighs its cost? I think that a lot
of UB doesn't actually help anyone and is just there out of
carelessness, or laziness.
Mainly historical reasons, I think. When C was first being
developped, using Sethi-Ulmann numbers were state of the art
optimizing, and they imply being able to reorder exceptions.
Today, of course, opimization techniques have evolved immensely,
and in practice, I don't think that this freedom really buys the
implementation much.
Perhaps just for C compat? If so, this simply
passes the buck to C.
It'd also be interesting to hear from people familiar with the upcoming
C++ standard about whether UB is being mitigated in any way.
We're adding to it:-). We can't avoid adding to it, since we
are adding support for threading---and thus, a whole new realm
of possible undefined behaviors.
It would be nice if we did define things like the order of
evaluation, but there doesn't seem to be a consensus to do so.
--
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! ]