The D Programming Language
in [C++]
|
From: Walter Bright on 21 Nov 2006 22:37 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. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: AJ on 21 Nov 2006 22:30 Earl Purple wrote: <snip> > casting a void * to a pointer to a function is undefined behaviour. > > But dlsym() which is a POSIX function returns a void * which often > needs to be cast back to a pointer to a function. I don't see why there needs to be undefined behavior in this instance, or even the more general case. Foo foo; // Well-Defined. Foo* foo = new Foo; // Well-Defined. Foo* foo = dlsym<Foo>(); // "Would be" Well-Defined, if it existed. If the cast/process fails, you could do one of two things: a) Throw (as does dynamic_cast by reference). b) Return NULL (as does dynamic_cast by pointer). See? No need for UB. C is an arcane, unsafe, weakly-typed, very user-unfriendly language. C++ is not C :P. Cheers, -Al. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: AJ on 21 Nov 2006 22:38 Gabriel Dos Reis wrote: > Walter Bright <walter(a)digitalmars-nospamm.com> writes: > > [...] > > | > I am very happy when I can implement, or extend, some feature without > | > specific compiler support. > | > | There's no way you're going to get std::string, std::vector or > | std::complex to work as well as core support for such with existing C++ > | core features. > > 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? > He already has. (Dynamic) Strings and (Dynamic) Arrays are just as common and important in the vast majority of programs as Integers. Integers are an intrinsic part of the language, yet they don't need to. I see no indication that a language couldn't get away with a single type -- bit -- and everything else left to the library. Thus, the same argument applies to strings and arrays. To be fair, std::string and std::vector are fairly impressive bits of work, considering how they are constrained. But their deficiencies show up everywhere. Can you imagine having to do: #include <integer> // Binary for 32, because remember, you don't have int literals. typedef std::integer<0, 0, 1, 0, 0, 0, 0, 0> int32; void displayAnswer(const int32& answer) { cout << "The answer to the life is: " << answer << endl; } const int32 main() { try { cout << "2 + 2 = " << int32(1, 0) + int32(1, 0); cout << endl; displayAnswer(int32(1, 0, 1, 0, 1, 0)); } catch (...) { return int32(1); } return int32(0); } For even trivial programs? It'd get real messy in a hurry. Similar hassle is incurred currently because of the lack of native dynamic arrays and strings. I think better support for these is very important. Here's one radical suggestion for the next C++ standard: string literals could be of type std::string (instead of const char*). string literals prefixed with L could be of type std::wstring (vs. const wchar_t*). array literals could be of type std::vector (instead of T*). These are already part of the language, so why not rely on them? Just food for thought. Cheers, -Al. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 21 Nov 2006 22:36 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? 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. 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. 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). -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Greg Herlihy on 22 Nov 2006 06:10
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. 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? 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?). Even more troubling than the inaction on this front, is that few - if any - of those involved in C++0X process seem to appreciate the seriousness of the problem. More than any other single factor, it is the undefined behavior in C++ that is most likely to end C++ long career as a major programming language and could do so in very short amount of time. 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. Those of us who are C++ programmers may be tempted - as a response - to deride the programming skills of, say, a Java or C# programmer, or to criticize those languages for any number of shortcomings when compared to C++ - and although we may well be justified in our opinions - our being right will not be enough to save the C++ language from market forces. Because I believe that it is those who pay to have software written, not those who are paid to write software - who will decide the fate of programming languages in this day and age. And if I am correct (and I'm as big a fan of C++ as anyone), then - unless something more is done - C++'s days as a major programming language are numbered. Greg -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |