The D Programming Language
in [C++]
|
From: Gabriel Dos Reis on 22 Nov 2006 06:48 Walter Bright <walter(a)digitalmars-nospamm.com> writes: | Alf P. Steinbach wrote: | > * Walter Bright: | >> Alf P. Steinbach wrote: | >>> But even if so, how does an Imaginary type help with that, when x+i*y | >>> can always be represented as Complex(x,y) and vice versa? | >> | >> This explains it better than I can: | >> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf | > | > Forgive me if I failed to find the quote you intended in that long | > document. | | See page 15. I'm sure you can give us an explanation in simple terms for those of us who are struggling in removing anti-Sun rants, just to get to the technical arguments. -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 22 Nov 2006 06:50 Walter Bright wrote: > Gabriel Dos Reis wrote: > > So, the question is: Can there be better library implementations, or > > can the core language be extended to allow better library > > implementation? (e.g. allow for literal of user-defined types), > > or do you think that there are *intrinsinc* reasons why they must be > > core languages? If yes, could you elaborate on those logical, > > intrinsinc, reasons? > A compiler will always be more powerful than what's possible with the > library, for the intrinsic reason that one can code the compiler to do > whatever one wants to. With a library, you're stuck with what the > compiler chooses to make available. I think that's pretty obvious, since > there are no examples of languages where libraries are as powerful as > the compiler. If it was possible, out of the thousands of languages > invented, certainly one of them would have done so? I'm not certain what you're trying to say. In many functional languages, the distinction between what is compiled and what is part of the core language is very vague; in Lisp, the language existed as a library only before there was a compiler. The distinction is clearer in C++, although there are vague points, like std::type_info. I think it's true that in most procedural languages today, there is no way of defining totally new syntax without modifying the compiler, but this is a constraint of the particular languages, and not something fundamental. The macro pre-processor for Intels ASM 86, for example, allowed defining new syntax; a function was called by matching a pattern, and the function definition defined that pattern. It can be done. It has been done. (But of course, at present, C++ doesn't do it.) > To improve upon the current abilities to create user defined types, one can: > 1) allow user defined literals > 2) allow user defined syntax > 3) allow user defined semantics > Currently, C++ (and D) only allow (3), and only to a limited extent. I believe that there is a proposal before the committee to support 1---the question was discussed, at any rate. > You've alluded to a C++ proposal for (1), I haven't seen it so have no > useful comment about it. I know that D, at least, will not have user > defined tokens, for the reason that such would blow the legs off of > third party tools that process source without needing to be full blown > compilers. For every advantage, there are drawbacks. Since C++ has the preprocessor it has, the legs (and even a bit higher) are already blown off of third party tools that process source code, so the added cost would be less. If you point is just that language design (and library design) is a very difficult balancing act, I've no problem agreeing. If you're claiming that the standard string type in D is superior to that in C++, I can only say that I wouldn't be surprised (even without knowing the standard string type in D), but that surprisingly, std::string actually works a lot better in practice than one would think it should in theory. > 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). (2) already exists in C++: #define IF if ( #define THEN ) { #define ELSE } else { #define ENDIF } // ... Which is, of course, one of the reasons why C++ is the hardest language in existence to parse. -- 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: Bo Persson on 22 Nov 2006 09:36 Greg Herlihy wrote: > Frederick Gotham wrote: >> AJ: >> >>> Can someone with a C++ implementation background actually confirm >>> that the great hassle that is UB significantly benefits the >>> implementation? >> >> >> What great hassle is there with UB? Either you can do something in >> Standard C++, or you can't. Simple as. >> >> 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. It would only be portable to those systems where the stricter specification could be implemented. As a developer you can also avoid som UB by restricting your intended target to a subset of the existing machines. Frederick's problem here can be avoided by specifying a minimum of 17 bits for type int. I started my career programming 8-bit Z80 machines, and now have a dual-core Athlon 64. I don't really care if my programs port easily between these two machines. They aren't used for the same things anyway. > > After all, there is more than a slight absurdity in the very term > "undefined behavior". 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? Computers are different. By not specifying each low level detail, C++ can be *efficiently* implemented on more types of computers. > > And to make matters worse, the C++ Standards Committee does not > appear to have made any significant effort at eliminating even a > few of the more preposterous cases of undefined behavior in the > current C++ Standard (can't a modern computer even shift bits in a > predictable way?). No, they cannot. Specifically, different members of the Intel x86 series shift by a different amount, when the shift count is larger than the register width. Even though they use the same binary instruction. So the C++ standard says that the result is undefined. How do we fix that? > 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. On the mainframe I program for, IBM had to add special Java processors to make it run fast enough, because the behaviour of their other hardware didn't exactly fit the Java spec. Talk about EXPENSIVE! Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jakob Bieling on 22 Nov 2006 10:18 Walter Bright wrote: > But I do have a couple challenges for you <g>. > 2) Extend std::string to support strings with embedded 0's. Doesn't std::string support exactly that by default? regards -- jb (reply address in rot13, unscramble first) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 22 Nov 2006 10:14
In article <1164168814.447157.127010(a)h54g2000cwb.googlegroups.com>, Greg Herlihy <greghe(a)pacbell.net> writes >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. And what you seem to miss is that C++ is a general purpose programming language designed to be useful on many platforms. There are two major areas of undefined behaviour: 1) Places where requiring diagnosis is very expensive (or in some cases, equivalent to solving the halting problem). This is particularly true of problems arising from separate compilation. Some possible breaches of the ODR are very subtle (though any well taught programmer will avoid them) 2) Places where portability is essentially impossible because of different hardware having different requirements. It is interesting to note that even languages like Java that target a single platform (the JVM) exhibit undefined behaviour. At least C++ has the honesty to identify the problem areas. -- 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! ] |