The D Programming Language
in [C++]
|
From: Mirek Fidler on 21 Nov 2006 15:53 Well, my main compaint about the D language is that Walter wastes his time on this project and therefore has no left for makeing his C++ compiler more usable (standard compliant, more platforms). What a pity, we might have choice between GCC and DMC.... Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 21 Nov 2006 17:05 AJ <two(a)haik.us> writes: > It would also be unfair to consider library support as good as core > language support for (at least) two reasons: > > 1) Syntax. > 2) Convenience. Not necessarily. My ideal language would allow me to create library support whose syntax and convenience are, in most cases, just as good as that of the best possible core-language design. -- 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: Walter Bright on 21 Nov 2006 17:07 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 > Furthermore, what is the relevance to library versus built-in? None. The relevance is to the lack of an imaginary type for C++ (library or built-in) and what such lack says about serious numerical analysis use. Note that C99 does address this and includes an imaginary type. So does D. -- [ 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 17:15 James Kanze wrote: > But the argument that C++ doesn't have a string type is false. > It does. I didn't argue C++ didn't have a string type. I argued that: 1) library features are not part of the core language. 2) C++ (and D) do not have good enough core features to be able to create a library string (and vector, complex and associative arrays) that are good enough to compete with core support for such. 3) String, complex, vector and associative arrays are ubiquitous enough that the extra goodies one can get with a core feature make them worthwhile to put in the core language. -- [ 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 17:16
Bo Persson wrote: > Requiring compiler support doesn't make a feature clean, it makes it dirty. I tend to feel that what makes a language dirty is when it's loaded with special cases and arcane rules. A clean language is not necessarily one with a small number of features, it is one with features that are orthogonal yet fit together in a predictable and sensible manner. > I believe that's where James and I disagree with Walter. > If you have a core language support that allows std::string to be > efficiently implemented as a library, that means that other similar classes > can be efficiently implemented as well. By someone other than the compiler > writer. > > The fact that it can be done as a library only, with no specific magic, > actually shows that the language is stronger, not weaker. D can, as well as C++ can, create library defined strings, vectors, etc. I get the impression you feel that D somehow sacrificed the ability to create user defined types by adding core support for arrays and strings. > The fact that Walter designs and implements his own language, > puts him in a > different position than most of us. Perhaps that influences his point of > view? Or maybe his views is the reason for doing it? Actually, it was using languages that did support strings and arrays much better than C++ that led me to want much better than what could be done with a library. Maybe it's a coincidence that such languages are almost always considered to be easier to learn, use and more productive to program in than C++. Strings and arrays are ubiquitously used, so even small improvements in their usability can pay big dividends in the long run. > 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. But I do have a couple challenges for you <g>. 1) Extend std::string to support UTF-8. 2) Extend std::string to support strings with embedded 0's. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |