Re: Undefined behaviour [was Re: The D Programming Language]
David Abrahams wrote:
"James Kanze" <james.kanze@gmail.com> writes:
David Abrahams wrote:
"James Kanze" <james.kanze@gmail.com> writes:
And there are plenty of programs with incorrect logic that is allowed
by both languages. In C++ that incorrect logic may lead to undefined
behavior, which is detectable by tools at runtime. In Java it cannot.
Or can. It depends on the error. And the tools.
I would like to see one example, then. AFAICT it's as simple as this:
Java has no undefined behavior (notwithstanding that you seem to use
"undefined" in some other sense, from a language specification POV,
there is none IIUC).
I'm using it in the everyday sense.
AFAIK there is no "everyday sense" that's different from the one used
in the standard. We should stick to well-understood terminology
especially for standard terms here, or we'll just end up with horrible
confusion.
I think that the standard attempted to put the "everyday sense"
in more or less formal terms. Never the less, I don't consider
that my implementation "defines" the behavior of accessing an
uninitialized pointer, just because it does guarantee that it
won't cause nasal demons to come out of my nose, or even because
it guarantees that I won't reformat the hard disk.
And I think that this is the real issue between what Andrei is
arguing and what I am saying. Where is the limit where
"undefined behavior" ceases to be "undefined"? The fact that
nasal demons can't come out of my nose? Would the simple
statement somewhere in the C++ standard that this behavior isn't
allowed mean that C++ doesn't have "undefined behavior"?
The everyday sense I'm talking about is simply that if a
behavior isn't defined, it is undefined.
Java has no acknowledged undefined behavior. Unless you
consider that its inventors were divinely inspired, and somehow
protected from the errors which the rest of us make, whether it
be in programming or in writing a specification, you should be
sceptical of such claims. They're along the same lines as
claims that a non-trivial program has no errors.
No they're not. Undefined behavior means one thing: the language
specification intentionally gives you no guarantees about what can
happen in a conforming implementation. Either such conditions exist
in the Java spec or they don't. It's very cut-and-dried.
And what about the cases where the language specification
doesn't say anything? What about the more complicated cases,
where there are several different variables involved, and the
possible results include raising an exception? And there is no
possible way to know in advance which of the possible results
will occur.
Therefore anything a Java program is a legal use of the JVM.
Therefore no tool has license to tell me my program has gone awry
unless I also give that tool lots of additional information about the
program's invariants.
Just one example, please, to show me where the flaw in my logic lies.
I don't see any logic to find a flaw in.
Well, I just wrote A therefore B therefore C. That was a chain of
logical reasoning. Or are you also using "logic" in some "everyday
sense?"
No, but just inserting "therefore" in front of specious claims
doesn't turn the sequence into logic. Not every possible Java
program is a legal use of the JVM; the Java specification is
quite clear that you don't have the "right" to modify variables
in several different threads at the same time, for example, but
the compiler will not reject it. (Note that this is different
from the argument concerning undefined behavior. The language
specification can define what happens at runtime if you do something
illegal, while still considering it illegal.)
Secondly, of course, a tool can tell you anything the tools
authors want, regardless of the language specification. In C++,
it's fully legal, and defined behavior, to write the intializers
in the initializer list of a constructor in any order you wish.
The tools I use, however, tell me if I've written them in a
different order than the order in which they will be used.
Leaking memory is legal and well defined behavior in both Java
and C++, but there are tools for both languages which will tell
you if you do.
Purify is a good example of an external tool that has no use in
Java. Most of the errors Purify catches simply wouldn't be errors
in Java; they're errors which occur because C++ requires dynamically
allocated objects to have explicit lifetime, even when the program
logic doesn't.
That depends on the object references/pointers actually having
intended shared semantics, but not all object references work that
way.
Agreed. Purify doesn't find all of the errors in C++. So what
else is new? Some objects have state, and what you can do with
a given object depends on, or may depend on, its state. Purify
can't detect when you try to do something with an object, and it
isn't in the correct state. Unless that incorrect state is
"lifetime of object has ended", and the function used to set
that state is a delete expression. It's a special case, and a
useful one to be able to catch, but it's not the only one, and
for many (most?) objects, it's not a relevant one. When it's
relevant, it's easy to add the code to catch the error in Java,
and the code is simple and rapid enough to leave in production
code. And is no more complicated than the code you have to add
for any other cases of invalid state.
The difference is that the C++ memory model requires that this
state be relevant for all objects, regardless of the design
requirements, and that it makes it practically impossible to
detect the error except with overly complex external tools with
runtime penalties too high to allow their use in production
code.
(With luck, this will be fixed in the next version of the
standard.)
For those that it catches which would also be an
error in Java (because the program logic required an explicit
lifetime, and you access the object after that lifetime, for
example), it would be simple to add the test in Java, to detect the
error.
Yes, I note you say "add the test." That's one test that can't be
automated and must be written by hand. And to write that test you
have to anticipate that it might be a problem. The problem, of
course, is that people can't always anticipate all the potential
problems, which is a major cause of program bugs.
The reason it has to be anticipated is that it isn't usually a
problem. C++ requires you to specify an explicit lifetime for
every single object; Java (and C++ with garbage collection)
doesn't, and in fact, objects with explicit lifetimes tend to be
the exception. (They also tend to derive from specific
interfaces, so you could logically add the explicit test in one
or two interfaces, and cover all of the cases. Except, of
course, that Java doesn't allow it---C++ with garbage collection
does, however.)
So the current situation is basically that the language forces
you to create a lot of additional error cases, and then says,
yes, but an external tool can be used to detect them.
In addition, the added tests cost little enough that you could even
leave them in in production code, which is not the case with Purify.
Or were you thinking of some other type of tool?
There are cases where the error in C++ "simply wouldn't be an error in
Java." There are also cases where the error in C++ would be an error
in Java with a different manifestation.
Agreed. My points are simply that 1) the cases where it would
be an error in both languages aren't that frequent; that in most
cases, the fact that it is an error in C++ is an artifact of the
language, and 2) in the cases where it is an error in Java, it's
easy to add code to do the check, and since the cases aren't
that frequent, the runtime cost is low enough that such code can
be left in delivered code.
(I guess I should stress that everything I say about Java here
applies equally as well to C++ with garbage collection. And
that there are a lot of other aspects of Java that I don't like;
enough so that globally, I still prefer C++ to Java.)
--
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! ]