The D Programming Language
in [C++]
|
From: Jean-Marc Bourguet on 22 Nov 2006 10:14 Gabriel Dos Reis <gdr(a)integrable-solutions.net> writes: > | I don't think (2) can ever happen with C++, for the reason that it's > | very hard to see how user defined syntax could ever be retrofitted in to > | a language that is already the hardest language in existence to parse > | (by a wide margin). > > I don't think your categorization of (2) is adequate. C++ has been > offering (3) for more than 2 decades now. There are several ways of > doing (2) without necessarily having user defined tokens. One of them > is to allow users to attach their meaning to tokens. One interesting approach for (2) is the Scala (http://scala.epfl.ch) one. It would be interesting to see how well it could be imported in C++. They don't really have user specified syntax, but the langage syntax is flexible enough to be able to define repeat and until so that repeat { some code here } until (cond); does the same as do { some code here } while (!cond); in C++. And at first look it seems to be that an efficient implementation is possible. A possible problem is the understandability of error messages. Yours, -- Jean-Marc [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jiang on 22 Nov 2006 10:35 Greg Herlihy wrote: > Frederick Gotham wrote: > > AJ: > > [snip] > > It is important to understand that undefined behavior in C++ is not a > threat because it makes C++ programmers yearn to program in other > languages (though who knows? it may), nor does it make C++ less > efficient than other languages (actually it usually has the opposite > effect). Rather, the threat posed by undefined behavior is purely one > of economics. A computer language with completely defined behavior > (such as Java) translates into cheaper programmers (because they are > less skilled) translates into the same or fewer programming defects > (because programming mistakes are harder to make and more easily > detected in time) and even translates into a shorter development cycle > (because undefined behavior may mask bugs that take longer to find then > a program whose behavior is known to be completely defined). Cheaper, > better, faster - those are the threats to C++'s continued relevance. > Yes, I see your points, but 1. It is not that useful to compare Java with C++ here. The two languages evolve in quite different ways. There is no one single company/vendor can dominate the behaviors of C++. 2. Fact 1: even we had a standard (yes, lots of UB) almost 10 years ago, we do not have a 100% standard compliant compiler. 3. Fact 2: We do not have an standard ABI, which makes it almost impossible to remove all the UBs in the C++ standard. These issues are out of the control of C++ committee in my mind. 4. I am just worrying about that even we have a completely defined standard, it will become a second class standard. Just think about export keyword, instead of trying to add it, one major compiler vendor was trying to remove it. Another vendor disabled it before shipping it. To repeat myself, I see your points, but I do not think this is possible in recent future. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pierre Asselin on 22 Nov 2006 10:51 Greg Herlihy <greghe(a)pacbell.net> wrote: > Hasn't anyone ever wondered how exactly the C++ > Standard is able to find so much undefined behavior in the execution of > the most deterministic finite state automaton ever invented - the > modern computer? What do you mean by "the" modern computer ? -- pa at panix dot com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Hopkin on 22 Nov 2006 15:31 On Nov 22, 11:10 am, "Greg Herlihy" <gre...(a)pacbell.net> wrote: > A computer language with completely defined behavior > (such as Java) translates into cheaper programmers (because they are > less skilled) translates into the same or fewer programming defects > (because programming mistakes are harder to make and more easily > detected in time) and even translates into a shorter development cycle > (because undefined behavior may mask bugs that take longer to find then > a program whose behavior is known to be completely defined). In practice, the result can be the opposite. C++ compilers will very often turn undefined behaviour into a core dump (wherever it is practical to do so on the platform in question). In some other languages of note, the result of defining this behaviour has been that exceptions are thrown a) where there's no sensible means of recovery and b) those exceptions can get swallowed up in exception handlers, so that the program limps on in an undefined state, making for extremely hard to catch bugs I think there *is* too much undefined behaviour in C++, but simply having all behaviour defined isn't necessarily an improvement. James -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Frederick Gotham on 22 Nov 2006 16:35
Greg Herlihy: >> If one writes portable code whose behaviour is not defined by the C++ >> Standard, then that's _their_ problem. > > No, the very fact that it is even possible to write a non-portable > program is a problem that could only exist because the C++ "Standard" > is incomplete. In other words, what the Standard euphemistically calls > "undefined behavior" is nothing more than those areas of the C++ > language that have yet to be filled in. And if those areas were ever to > be filled in, then concerns about "portable code" would all evaporate - > because every C++ program would be portable. The naivety astounds me! We could rid Standard C++ of all its undefined behaviour, but then it wouldn't be nearly half as powerful! Consider system code that does something like: *(unsigned*)0x0000007F = OUTPUT_ENABLE|INPUT_FREEZE|FAIL_BIT_OFF; This statement might have a very particular purpose on a particular system. But do you think the C++ Standard should have to define its behaviour? Three choices: (1) Necessitate the implementation to define its behaviour. (2) Prevent it. (3) Leave its behaviour as undefined. Option 1 will be a pain in the neck for compiler implementors. Why should the developers of the new Playstation compiler sit around worrying about programmers writing to arbitrary memory addresses? Option 2 strips C++ of its power. Now we can't do what we wanted to do on the implementation in question. Option 3 is a compromise. We don't annoy the compiler developers, yet at the same time C++ retains its power. Seems to me like Option 3 is just fine. -- Frederick Gotham [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |