The D Programming Language
in [C++]
|
From: Binglong X on 1 Dec 2006 14:56 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? 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. > > The moral of the story is that C++ is way too flexible to justify > another similar language - even if C++ has some some features that make > seasoned compiler writer cry :) > I do not believe C++ is a Terminator of its akin. I would think Java, C# and so on are among the C++'s "similar languages", but they do have reasons to exist. Maybe D as well. 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. The coding gurus know the traps, and can reap through the flexibilities; The very large C++ programmer population are not in that level, and some of them may not come to that level for ever given the difficulty of learning advanced C++ features. Flexibility is never free; it comes with possible misuses and slower learning curve, etc. Too much flexibility then could be a killing factor for beginners -- they want simple, understandable, and predictable coding. By carefully examining what are the desirable flexibilities and what are not, it is possible to improve C++. If there are a lot of such improvements that are not able to be incorporated into C++, maybe due to its legacy burdens, I see the opportunity of a new language. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 1 Dec 2006 14:53 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. :-) -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 1 Dec 2006 14:50 Andrei Alexandrescu (See Website For Email) wrote: > 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? > 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. But nobody's really disagreeing. Being able to accidentally randomly overwrite memory is hardly what I would call a feature. (Being able to do it intentionally, e.g. with a reinterpret_cast, is a necessary feature if you want to develope kernel code, but that's a different issue.) On the other hand, faced with a serious program error (e.g. inconsistent values resulting from a race condition), having all hell break loose is certainly preferrable to silently continuing and pretending that all is well. And issuing a market order to buy when our customer said sell. > > 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++. > 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. That's not been my experience. I found debugging Java programs exceedingly difficult---the event handler in AWT/Swing silently ate all exceptions, so when you dereferenced a null pointer, you simply silently didn't finish handling the event, rather than crashing noisily. More importantly, of course, I found writing correct programs in Java considerably more difficult, because everything derived from object, and your collections weren't typesafe. Which meant I had a lot more debugging to do---in general, in C++, if my code passes the compiler, it works. (Not always, of course, but in general, after successful compilation and code review, I can count on one error per 100000 lines of code in C++, but close to 10 times as many in Java.) I'm not sure how such personal anecdotes relate to the undefined behavior issue, however. I don't think that there's any doubt that Java has a lot less undefined behavior than C++: you claim zero, and I claim that there are a very few special cases, where as C++ has it all over the place. I don't think that there's any doubt either that undefined behavior is bad, in itself. And I certainly hope we agree that it is only one factor, and that there are a lot of other factors which affect the difficulty of writing correct code, or debugging incorrect code. (The biggest problems I had in debugging Java were due to the defined behavior doing the wrong thing---throwing an exception rather than crashing---and an incredibly stupid decision to ignore the exception in the standard library. That and the lack of strong typing on variable sized containers---I understand that has since been fixed.) > I remember __to this day__ a night in 1998 when a colleague > and myself spent one night figuring out a completely weird exception > being thrown (in a C++ program) under very complex circumstances - just > because of a misfit memcpy() in a completely different and unrelated > part of the program. Now that I think of that, I remember a few others. > Probably I'd remember even more under hypnosis :o). To tell the truth, I > also remember of a JVM bug causing me a few gray hairs... :o) But that's defined behavior in Java. According to the standard, if the JVM has a bug, it's supposed to throw the VirtualMachineError exception, no? :-) (FWIW: the bug that took me the most time to find was when the hardware changed a bit in the program. Always the same bit, and only once or twice per day. Memory wasn't protected back then, and it took us well over a month to determine that it was hardware, since all of the hardware tests said that everything was fine.) -- 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: David Abrahams on 2 Dec 2006 02:58 "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail(a)erdani.org> writes: > 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. > > Explaining this any better is beyond my abilities. 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). 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. -- 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: Andrei Alexandrescu (See Website For Email) on 2 Dec 2006 03:04
James Kanze wrote: > Andrei Alexandrescu (See Website For Email) wrote: >> 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. > > But nobody's really disagreeing. Being able to accidentally > randomly overwrite memory is hardly what I would call a feature. > (Being able to do it intentionally, e.g. with a > reinterpret_cast, is a necessary feature if you want to develope > kernel code, but that's a different issue.) > > On the other hand, faced with a serious program error (e.g. > inconsistent values resulting from a race condition), having all > hell break loose is certainly preferrable to silently continuing > and pretending that all is well. And issuing a market order to > buy when our customer said sell. The problem is that the hell could break loose by also issuing a market order to buy when our customer said sell. The problem with a program is not that it crashes - that would be great - but that it can do anything, including not crashing. I guess the set of "all hell breaks loose" is much larger, and includes, the set "there is one incorrect value". I am sitting here in amazement I have so much trouble getting this point across. >> 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. > > That's not been my experience. I found debugging Java programs > exceedingly difficult---the event handler in AWT/Swing silently > ate all exceptions, so when you dereferenced a null pointer, you > simply silently didn't finish handling the event, rather than > crashing noisily. So I guess you have libraries that suck. Nothing new :o). > More importantly, of course, I found writing correct programs in > Java considerably more difficult, because everything derived > from object, and your collections weren't typesafe. Which meant > I had a lot more debugging to do---in general, in C++, if my > code passes the compiler, it works. (Not always, of course, but > in general, after successful compilation and code review, I can > count on one error per 100000 lines of code in C++, but close to > 10 times as many in Java.) > > I'm not sure how such personal anecdotes relate to the undefined > behavior issue, however. I don't think that there's any doubt > that Java has a lot less undefined behavior than C++: you claim > zero, and I claim that there are a very few special cases, where > as C++ has it all over the place. I am eager to hear about the few special cases, and I have tried to substantiate my point with what I found on the net. Would somebody please oblige. > I don't think that there's > any doubt either that undefined behavior is bad, in itself. And > I certainly hope we agree that it is only one factor, and that > there are a lot of other factors which affect the difficulty of > writing correct code, or debugging incorrect code. (The biggest > problems I had in debugging Java were due to the defined > behavior doing the wrong thing---throwing an exception rather > than crashing---and an incredibly stupid decision to ignore the > exception in the standard library. That and the lack of strong > typing on variable sized containers---I understand that has > since been fixed.) So we have bad libraries and a problem that's been fixed... pretty nice. To be honest, the first problem I've had in my Java apps was that it's slow like molasses running uphill on a cold day in rough terrain for what I'm doing in my research. Our lab actually has a ban against running Java or much Perl on the computing cluster, because it just wastes precious resources. Perhaps they could be talked into allowing D :o). Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |