The D Programming Language
in [C++]
|
From: Andrei Alexandrescu (See Website For Email) on 2 Dec 2006 03:06 James Kanze wrote: > Andrei Alexandrescu (See Website For Email) wrote: >> This section can be understood only if we know what a Java program does >> once it's read an invalid (say, NaN) value. Will it crash? > > Can the VM avoid crashing, if the OS decides that that is what > it wants to do? > > More to the point, does the fact that a Java program cannot > crash (IF that is the case) mean that Java has no undefined > behavior, or is it more or less a specious guarantee, with about > as much meaning as if C++ added a guarantee that no C++ program > could make demons fly out of your nose. Do my programs suddenly > loose all undefined behavior if I set SIGILL, SIGBUS, SIGSEGV > and SIGFPE to ignore at the start? You misunderstood my question. I asked "Will it crash?" with hope. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 2 Dec 2006 03:03 Francis Glassborow wrote: > In article <J9KwII.1LMH(a)beaver.cs.washington.edu>, "Andrei Alexandrescu > (See Website For Email)" <SeeWebsiteForEmail(a)erdani.org> writes >> 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. > > If the program was for a safety critical task I do not think I would > distinguish. Well al hell breaks loose might just be better than getting > a 100 times overdose of X-rays. :-) I agree with your point, however I hope you'll also agree that a program with one wrong value is easier to debug than a program in which you have absolutely no guarantee to go by. To summarize, I guess I'd say that you have a chance to assert() against a bad value, but you can't do much if you can't even rely on assert() working properly. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 2 Dec 2006 14:36 Gabriel Dos Reis wrote: > Fortunately, not all compilers out there made the decision to actively > unsupport abstractions like the Digital Mars compiler. Name one that returns std::complex values in a register pair. gcc for the x86 (the C compiler) doesn't even return double _Complex or long double _Complex in a register pair. (It returns them on the stack. Strangely, it returns float _Complex in the DX:AX register pair, which is even worse.) Furthermore, your ABI quotes are clear that if a type has a non-trivial constructor (which std::complex has), it cannot be passed/returned in registers. And lastly, if a UDT really does have trival constructors and destructors, DMC++ will return them in a register. In fact, it was the very first C++ compiler to do so. 15 years later, g++ (for the x86) still does not return structs of any sort in registers. For example (I think we can agree that Foo doesn't get any more trivial!): ------------- C++ ------------------ struct Foo { int x; }; Foo bar(int i) { Foo f; f.x = i; return f; } ------------- g++ ------------------ _Z3bari: pushl %ebp movl %esp, %ebp movl 8(%ebp), %edx movl 12(%ebp), %eax movl %eax, (%edx) movl %edx, %eax leave ret $4 ----------- DMC++ ------------------ ?bar@@YA?AUFoo@@H@Z: mov EAX,4[ESP] ret ------------------------------------ g++ is returning f on the stack, DMC++ in register EAX. I don't see a basis for your statement that DMC++ "unsupports" abstractions compared with other compilers. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Greg Herlihy on 2 Dec 2006 14:38 David Abrahams wrote: > "Andrei Alexandrescu (See Website For Email)" > <SeeWebsiteForEmail(a)erdani.org> writes: > > > There might be a terminology confusion here, which I'd like to clear > > from the beginning: > > > > 1. A program "has undefined behavior" = effectively anything could > > happen as the result of executing that program. The metaphor with the > > demons flying out of one's nose comes to mind. Anything. > > > > 2. A program "produces an undefined value" = the program could produce > > an unexpected value, while all other values, and that program's > > integrity, are not violated. > > > > The two are fundamentally different because in the second case you can > > still count on objects being objects etc.; the memory safety of the > > program has not been violated. Therefore the program is much easier to > > debug. > > Seriously? > > IME you're at least likely to crash noisily close to the undefined > behavior. If you make everything defined the program necessarily > soldiers on until one of your own internal checks is able to notice > that something went wrong. Or am I missing something? The idea that "undefined behavior" equates to a program crash is a popular misconception among C+ programmers, and is one the reasons undefined behavior is often minimized as a problem in C++ programming. This argument is really saying that C++'s undefined behavior is not undefined at all - but instead results in the flawed program's termination. So by a serendiptious stroke of luck, it turns out that undefined behavior is the same as the ideal behavior - so how can undefined behavior be a problem? And much of the time, the C++ programmer is right: the undefined behavior does terminate the program - but no credit should go to C++. Rather it is the OS and the runtime that have filled in where the Standard has been remiss, by defining otherwise undefined behavior. An obvious example is the dereferencing of a NULL pointer - the consequences of which are undefined by the Standard, but defined on almost every modern architectures as a fatal memory access error. So the fact that this supposedly "undefined behavior" is in fact very well-defined on most platforms - is what leads to the common misconception among C++ programmers that all undefined behavior in the language leads to the same. But of course that is a very mistaken conclusion.. And in fact in none of these problematic examples cited in this discussion, lend any support to the believe that a C++ program would be any more likely to terminate than the Java program in the same situation. Certainly non-atomic accesses are likely to be too expensive to detect on a given hardware, and I'm not familiar with any such error. Of course the reverse argument could also be made: that C++'s undefined behavior be no different than that of the Java program, so C++ is none the worse of for it. But if undefined behavior were so well-behaved, then why can't the Standard just state that that is the case? > I don't have any real experience with Java, but Python generally > exhibits Java-like behavior, and I don't find it easier to debug than > C++. I have found Perl almost trivially easy to debug compared to a C++ program. With C++programming there are two levels of correctness to worry about: first, the program must behave correctly (that is, have defined behavior at all times) and, second, this correct behavior must match the behavior that the programmer wants. A Perl (or Java) programmer does not have to worry about the first level, the program is always behaved - in other words, it always does what the programmer tells it to do. So the only concern left is for the programmer to tell the program what it should be doing in order so that it can produce the expected (or "correct") results. So in essence a Perl programmer is already halfway done writing a program compared against the starting point of a C++ programmer, and this is before eiher programmer has written a single line of code (OK, that's an exagerration, but it is a valid point nonetheless). Greg -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 2 Dec 2006 14:59
Bo Persson wrote: > Andrei Alexandrescu (See Website For Email) wrote: >> It's very simple. In one case you have a program that preserves its >> own guarantees (e.g. there's no random overwriting of memory), but >> which has one numerical value that's invalid; that can't corrupt >> memory because there's no pointer forging. In the other case you >> can't count on pretty much anything. > > But what if that one value, incorrect and unpredictable, is part of an > airliner's auto pilot, or a nuclear weapons launch system? You don't build airliner autopilot systems that blindly depend on any value computed by a single program. You just don't. The first rule of airliner design for safety is "assume X fails...", where X is any part of any system. And I would hope that nuclear weapons launch system would be done to an even higher standard. To do any safety critical system, you approach the problem from both ends: "how do I make this system failproof?" and "when it fails, how do I keep flying?" { Regarding safety standards of nuclear weapons launch systems -- see <url: http://en.wikipedia.org/wiki/Davy_Crockett_(nuclear_device)>, "the device could be fired to a dangerously short range by an inept crew". ;-) -mod/aps } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |