The D Programming Language
in [C++]
|
From: David Abrahams on 3 Dec 2006 20:20 "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail(a)erdani.org> writes: > David Abrahams wrote: >> >> Let me try to help. I think you didn't mean to say "preserves its own >> guarantees," or at least that's a confusing way to put it. The >> *program's* guarantees, as I see it, are the ones made by the author >> of the program to himself and to his users, and in the presence of a >> programming error, those guarantees are out the window. In a language >> without undefined behavior, the guarantees of the underlying system >> are still there in spite of programming errors. In other words, >> executing "x + 1" still adds 1 to the value of x, and doesn't call a >> sorting routine (or whatever). > > Great, thanks. > >> That said, even in a system with no undefined behavior, we have no >> idea what the value of x (or anything else in our program) is after a >> programming error, so the ability to continue on with the program >> executing the instructions you thought you were giving it originally >> is not as valuable as it might at first seem. > > It's not "anything else in our program". It's "anything else in our > program that was affected by x" No, not at all. Re-read the scenario; "x" didn't necessarily have anything to do with the programming error. From a practical point of view, by the time your internal checks/assertions have detected that there's been a programming error by inspecting some piece of program state (call it Z), you have no idea how far the damage has spread. That is, the program's own guarantees are out the window. That goes for C++, Java, or any other programming language, and it's why I tell people that in that situation throwing an exception is almost always the wrong idea. > and because (say in Java) races only happen on numbers Meaning that in Java, all writes of "references" (a.k.a. pointers) are synchronized? > and because there's no pointer forging, that reduces to "any other > number that was affected by x", which considerably reduces the rot > in the program and the difficulty in spotting it. I guess all I can > say is that I tend to see that guarantee as much more valuable. :o) Than what? -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 3 Dec 2006 20:24 Mirek Fidler wrote: > Walter Bright wrote: > > Nevin :-] Liber wrote: > > > So what is it about C++ that is stopping you from applying the > > > optimization you use for the intrinsic complex to std::complex (and > > > then, in general, to objects that have a similar form to std::complex)? > > Having constructors causes problems for it. Even though indirection can > > often be removed by the optimizer, the decisions about how returns are > > done are made in the parsing stage, because it affects how constructors > > are set up to get the return type built on the caller's stack. The > > optimizer/code generator really only see the C-like result of all that. > Just to keep things clear, we are here speaking about non-inlined > functions, are we? I'm not sure it makes an important difference, since a compiler is free to inline any function it likes (and some compilers do inline functions not declared inline, if the profiler says they should). -- James Kanze (Gabi Software) email: james.kanze(a)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! ]
From: Vidar Hasfjord on 3 Dec 2006 20:25 Al wrote: > And here's how it should be: > > int[] array = [1, 2, 3, 42, 666]; > cout << array.size << endl; // 5 > > > People simply /expect/ an array to automatically know its size. Actually, an array in C++ knows its size --- its part of the type. In native C++, i.e. without using library features, the above is expressed as: int a [] = {1, 2, 3, 42, 666}; cout << sizeof a / sizeof a [0] << endl; // 5 Of course the native array has static size, and some may argue that's not very useful. Personally, I consider the static array the most fundamental building block of a system programming language, because it is so closely related to the von Neumann addressable memory model. In fact, references/proxies, pointers, dynamic arrays and strings can be built in terms of the static array. Unfortunately, the irregular treatment of the native array in C++ is IMHO the most fundamental and ugliest wart of the language. The way its type decays when passed around is simply traitorous. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mirek Fidler on 3 Dec 2006 20:25 Gabriel Dos Reis wrote: > Walter Bright <walter(a)digitalmars-nospamm.com> writes: > std::complex<double> > add(std::complex<double> x, std::complex<double> y) > { > return x + y; > } > > It produces, for a target that identifies itself as x86_64-suse-linux, > > _Z3addSt7complexIdES0_: > .LFB1756: > addsd %xmm3, %xmm1 > addsd %xmm2, %xmm0 > ret BTW, the really cool implementation would store complex in single SSE2 register and use single ADDPD opcode to perform addition. Interestingly, using intrinsics already present in GCC, it could be done even now as library solution. Which is in the end more fruitful approach than to introduce complex as fundamental type. Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 3 Dec 2006 20:20
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail(a)erdani.org> writes: > David Abrahams wrote: >> Jean-Marc Bourguet <jm(a)bourguet.org> writes: >>> >>>Instead you are writing to an object which was supposed to be out of >>>existence for a long time. In my experience, that give you the same kind >>> of elusive bugs. Excepted that purify pcan't help you >> >> >> I want to emphasize that point: when nothing is truly illegal (like >> those things that C++ says cause undefined behavior), there's no way a >> tool like Purify can tell you that the program did something wrong. > > But in a memory-safe program you don't even need Purify to tell you that > the program did something wrong. A logging module would suffice, and the > proof is in the trace. a. I don't see how the logging module can do that b. Anyway, that's often far too late to actually debug the problem. > The important tidbit that makes it all work is that bugs anywhere in the > program can't mess the logging subsystem. That's a useful characteristic. > Let's face it. Memory safety is too nice a property. It's nice, I agree. I don't know if it's "too nice." > If the argument is that it leads to messier languages and slower > programs, I'd agree. But IMHO the arguments brought in this thread > didn't carry much weight. > > 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. >>>and that random behaviour including crashes are replaced by >>>deterministic, often plausible but wrong results. >> >> >> Of course that can happen in a system with undefined behavior, too. >> That said, it looks like a wash to me: incorrect programs have >> different characteristics under the two systems but neither one wins >> in terms of debuggability. > > The memory-safe program wins because it never overwrites arbitrary > memory; so all objects unaffected by a bug respect their invariants. The same is trivially true of C++: all objects unaffected by a bug respect their invariants. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |