The D Programming Language
in [C++]
|
From: Walter Bright on 19 Nov 2006 23:20 Seungbeom Kim wrote: > Walter Bright wrote: > >> I don't believe there's much point to discuss library features in >> language X vs language Y because any library can be implemented in any >> language. >> >> [...] >> >> I don't know of any computer language that prevents one from writing >> libraries for it, even TECO (gads, I'm old). But certainly, it's the >> core features of a language that have a powerful influence on the style >> and ease of building libraries for it. > > Yes, you said it; but isn't it contradictory to what you said above? > For example, in Pascal you cannot write a single library procedure that > sorts both array [1..10] of integer and array [1..20] of integer. True, but you can write two library procedures to do it, the point being you *can* do it in a library. > Thus > it is important for the core language to have enough flexibility and > power to accommodate good library designs. Sure, we agree on that. > But considering only the core language features would be a serious > mistake; it would be an unfair disadvantage to a language which has > preferred library solutions to core language solutions. For example, > under that criterion, you would say "C99 can handle variable-length > arrays but C++ can't; C99 can handle complex numbers but C++ can't." I've done complex numbers in C long before C99. You can do it with a library in any language, including Pascal. Therefore, it's a fairly meaningless point of technical language comparison. > However, what is important is whether a programmer can do his/her task > efficiently with the language and the associated tools, not whether it > is done by the core language or by the standard library or by a > third-party library. Certainly, the richness of currently available libraries for a language affects what one can do with the language today. The ease of building reusable libraries for a language affects what one can do with it tomorrow. > Whether a language facilitates good libraries or it > hinders good development tools, much of the credit/blame is to the language. I agree, and that's why I prefer to talk about core language features when comparing languages. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 19 Nov 2006 23:13 AJ wrote: > One other serious legacy flaw in D (inherited from C/C++) is that it > doesn't do away with undefined behavior. It's close, I think, but it's > unfortunate that the holes aren't closed entirely. I agree with the need for getting rid of undefined behavior as much as possible, but in a systems oriented language it's hard to see how it can be gotten rid of completely. For example, casting an int to a pointer and dereferencing it will give undefined behavior, but that's a capability that's needed. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 20 Nov 2006 14:42 Bo Persson wrote: > The C++ language defines features that can optionally be implemented as a > library, or built into the compiler. The standard allows, but does not > require, specific compiler support for these features. In my opinion, they > are still part of the language. Such a design choice means that it combines the worst characteristics of a core feature (not modifiable/replaceable by the user) with the worst characteristics of a library feature (poor integration with the language). > The D language requires compiler support for strings, the C++ language > allows it. That doesn't mean that there are no strings in C++. As far as I know, there is no existing C++ compiler that implements std::string in the compiler. Furthermore, since it is required to be indistinguishable from a library implementation, it isn't in any useful sense part of the core language. C++ does have core strings (char[]) and core arrays (T[]), it's just that they were abandoned and (unofficially) deprecated rather than fixed. >> Isn't it a lot more interesting to discuss core language features >> that make it easier/harder to write certain types of code (and >> thereby libraries)? Given all the core changes proposed for C++, >> certainly a lot of people feel the core language support is >> inadequate. > > Some people feel the need for more features. I am not sure that they are all > widely missed by others. Variadic template arguments are not high on my wish > list, for example. Many advanced C++ library developers have demonstrated that one can get by without variadic templates. But with them, the sizes of some libraries can drop by 90%. Template improvements don't float everyone's boat. What is high on your core language wish list? >> But what I think is fruitful to discuss or not only pertains to >> what I decide to post - I don't control these discussions. I'm not >> a moderator here. > > It was I who didn't find it fruitful to compare the languages, when you > concentrate on a core only comparison. Without the string, vector, and > complex classes, C++ admittedly is just half a language. Strings and arrays (and to a lesser extent complex) are such fundamental types that relegating them to the library means missing out on the syntactic and semantic niceties one can get by putting them in the core. After all, would you want 'int' to be library only, and turn your back on all the goodies a language can offer through direct support of it? > I respect your opinion, but just don't find it interesting to discuss > languages from that point of view. That's your privilege and prerogative. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 20 Nov 2006 14:51 AJ wrote: > Seungbeom Kim wrote: > <snip> > > But considering only the core language features would be a serious > > mistake; it would be an unfair disadvantage to a language which has > > preferred library solutions to core language solutions. For example, > > under that criterion, you would say "C99 can handle variable-length > > arrays but C++ can't; C99 can handle complex numbers but C++ can't." > It would also be unfair to consider library support as good as core > language support for (at least) two reasons: > 1) Syntax. > 2) Convenience. That depends. Library support isn't as good as core support when it isn't as good. The fact that it is library and not core isn't a disadvantage per se---I'd say that almost the opposite is true. But you do have to compare the level of support; there are some things that simply cannot be supported in a library alone. > Here's one example: Multi-threading and thread safety. And this is one of them: you definitly have to specify at the language level when it is safe to access objects, and when not. > For 1: In D, this is achieved in a super-clean and succinct manner: > Adding a synchronized keyword. That, on the other hand, is a serious defect, at least if it is done as in Java. It forces locking to obey scope rules. > In C++, one must add error-prone boilerplate for critical > sections (or mutexes, or locks) and in general the syntax is > verbose and a hassle. I've never noticed this. My experience in Java is that the synchronized keyword is a major problem; it's much easier to write effective, correct code in C++ (using e.g. boost::mutex). > For 2: In D, synchronized is built-in. No need to download or > install anything else. No need to check additional > documentation on library usage. I'm not sure I understand this point: if the functionality is part of the standard library, there's also no need to download or install anything else, and what's the difference between having to check library documentation, and having to check language documentation? The standard library IS part of the language. > In C++, one must install and add a dependency to boost > (non-trivial) or pthreads (still non-trivial), or sacrifice > platform-independence and go Win32. Pthreads is delivered pre-installed on all of my platformes:-). But that's not the point. At present, there is no support for threading in (official) C++. Library or language. That is a weakness. A weakness currently being addressed by the committee. The final solution will doubtlessly contain both library elements and language elements---the library cannot possibly define what sequence points mean in a multi-threaded environment, and it would be completely silly to not use functions and classes to create new threads, mutexes, etc. (Note that Java uses the synchronized keyword principally because it doesn't have destructors, and has no other way of ensuring that a lock is released in case of an exception. One weakness leads to another.) > On the other hand, D isn't available by default almost anywhere, whereas > C++ is, so that's one disadvantage. A pretty serious one. For me, the absence of a compiler for Sparc under Solaris means that it's not even worth my time to find out more. > However, wasn't this the case with > C++ vs. C too, at some point? I'm not sure. The earliest C++ compiler used C as an intermediate language, so could easily be ported to any machine on which C ran. > One other serious legacy flaw in D (inherited from C/C++) is that it > doesn't do away with undefined behavior. It's close, I think, but it's > unfortunate that the holes aren't closed entirely. No language manages to completely do away with undefined behavior. Although C++ could surely do better in this regard; there's a lot of unnecessary undefined behavior. > > However, what is important is whether a programmer can do his/her task > > efficiently with the language and the associated tools, not whether it > > is done by the core language or by the standard library or by a > > third-party library. Whether a language facilitates good libraries or it > > hinders good development tools, much of the credit/blame is to the language. > 'Efficiently' is the key. Adding certain things to the core language can > improve efficiency by an order of magnitude. "Can be done at all" isn't > the same as "can be done simply and easily." :) Formally, if it is part of the standard library, the compiler can know about it, and do whatever is necessary. This is often the case for standard library functions (like memcpy) in C. To date, it's not become the case for anything in C++, at least to my knowledge, although the standard certainly allows it. I think, however, that part of the goal is to design things so that the compiler can do the job well, not just for standard components, but for any user defined class. -- 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: Frederick Gotham on 20 Nov 2006 14:58
Walter Bright: > I agree with the need for getting rid of undefined behavior as much as > possible, but in a systems oriented language it's hard to see how it can > be gotten rid of completely. My opinion is the total opposite: Leave behaviour as undefined all over the place giving plenty of freedom to the implementation. -- Frederick Gotham [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |