The D Programming Language
in [C++]
|
From: Walter Bright on 2 Dec 2006 03:01 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. :-) Programs that calculate X-ray doses should use two independently developed algorithms to do so, and compare the results for a match. Then, the matched result should go through a sanity check. The hardware itself should have hardwired limits on its output. And lastly, the machine should have very obvious and clear displays on what its output levels are. In other words, you should never, ever, ever, rely on the output of a single program for any life critical decisions. I don't care what language you're using. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: john.vermeer on 2 Dec 2006 03:02 Binglong X wrote: > Hello folks, > > I am not sure if this was brought up before, but this language is quite > interesting when compared to C++ (and others such as C, C#, Java): > http://www.digitalmars.com/d/index.html Not bad, but Pascal is better. { :-) -mod } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mirek Fidler on 2 Dec 2006 03:09 Binglong X wrote: > Mirek Fidler wrote: > > > > I dare to say that my current C++ coding easily beats, in terms of > > productivity of my problem domains, anything else out there. (But of > > course, I am biased ;) > > I am curious what your problem domains are? Actually, right now, pretty wide ;) SQL/GUI client/server apps (C++ is unbeatable there, thanks to operator overloading), graphics/GIS/raster image manipulation (C++ is great because of speed), word/document processing and development tools. > I dare not to say that a > computer language is the best for my problem domains such that it does > not need any improvement. Actually, when coding, I often see possible > improvements of C++, for example, small things like, "foreach" > (available in C#) to scan through a collection and save the possible > wrong index from a typo, such as in for(i,...) for (j...) and i can be > used for j for wrong cause in the inner loop from a typo. Well, you might misunderstood me. Of course, I see many possible improvements as well (my favorite is "override" :), but most of them are just small annoyances. For me, outstanding features of C++ are destructors (no need to care about releasing resources anymore), operator (and function) overloading (you can simplify many tasks by overloading, even if I must admit that many would consider my overloading techniques a little bit too crazy ;), macros (C++ gurus might not want to hear that, but I consider macros a great thing when C++ language features fail to help) and of course, templates to glue it all together. > C++ is very flexible, especially > with the template feature. However, C++ is not perfect and some of its > legacy features and connections to C make it hard to repair some its > weaknesses. Ah, I forget to say that one of great features is that C language included! :) Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 2 Dec 2006 03:01 Andrei Alexandrescu (See Website For Email) wrote: > Gabriel Dos Reis 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. >> >> Why is not that the value of the computation? >> >>> 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.; >> >> I don't see anything fundamental in that difference. > > 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? Wouldn't nasal demons be an advantage, in practice? Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 2 Dec 2006 02:59
Jean-Marc Bourguet <jm(a)bourguet.org> writes: > "Andrei Alexandrescu (See Website For Email)" > <SeeWebsiteForEmail(a)erdani.org> writes: > >> Well the only thing I can add is that in my limited experience, >> debugging Java programs is much easier because there's never the case >> that a dangling pointer misteriously overwrites some object it wasn't >> supposed to. > > 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 can'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. > 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. -- 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! ] |