C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  The D Programming Language Goto page 1, 2, 3 ... 13, 14, 15  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Binglong X Guest Posted: Sat Nov 18, 2006 1:29 am    Post subject: The D Programming Language Hello folks, I am not sure if this was brought up before, but this language is quite interesting when compared to C++ (and others such as C, C#, Java): http://www.digitalmars.com/d/index.html The comparison: http://www.digitalmars.com/d/comparison.html -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gennaro Prota Guest Posted: Sat Nov 18, 2006 6:29 am    Post subject: Re: The D Programming Language On 17 Nov 2006 14:29:44 -0500, Binglong X wrote: Quote: Hello folks, I am not sure if this was brought up before, but this language is quite interesting when compared to C++ (and others such as C, C#, Java): http://www.digitalmars.com/d/index.html The comparison: http://www.digitalmars.com/d/comparison.html Mumble mumble mods... how are we supposed to reply here? There's no question, just a general opinion. Perhaps that we only like C++ and assembly? :-O { One fruitful avenue of discussion might be how to emulate the pure D features in current C++, or how some of these features could or will be supported in the C++0x language or its standard library. -mod/aps } -- Gennaro Prota [To mail me, remove any 'u' from the provided address] -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jack Klein Guest Posted: Sat Nov 18, 2006 10:10 am    Post subject: Re: The D Programming Language On 17 Nov 2006 14:29:44 -0500, "Binglong X" <binglongx (AT) gmail (DOT) com> wrote in comp.lang.c++.moderated: Quote: Hello folks, I am not sure if this was brought up before, but this language is quite interesting when compared to C++ (and others such as C, C#, Java): http://www.digitalmars.com/d/index.html The comparison: http://www.digitalmars.com/d/comparison.html 1. Yes, it has been brought up before. 2. It was off-topic then, and it is still off-topic now. This group discusses the C++ language. Not the relative merits (in someone's mind) of C++ versus X, regardless of whether X is COBOL, FORTRAN, Forth, Ada, or anything else, except C. Try comp.programming if you want to discuss the relative merits of different languages. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Walter Bright Guest Posted: Sun Nov 19, 2006 9:31 am    Post subject: Re: The D Programming Language Bo Persson wrote: Quote: We have tried that before, but as the designer of the D language believes that we should compare core language only, and that features already implemented in the C++ library doesn't count, this avenue hasn't been very fruitful. 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. Heck, I once posted that a garbage collector could not be implemented in Java, and someone replied that it was possible and someone had done exactly that. I've even heard of a FORTRAN compiler written in TECO! 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. 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. Quote: Some of us, who are not compiler writers, actually see a great advantage in being able to add library features. 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. Building template libraries for C++ is a major source of activity and interest, so it's fun to compare it with D programming language templates: http://www.digitalmars.com/d/templates-revisited.html -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Seungbeom Kim Guest Posted: Sun Nov 19, 2006 10:10 am    Post subject: Re: The D Programming Language Walter Bright wrote: Quote: 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. Thus it is important for the core language to have enough flexibility and power to accommodate good library designs. 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." 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. -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Mon Nov 20, 2006 3:31 am    Post subject: Re: The D Programming Language Seungbeom Kim wrote: Quote: 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." And that Fortran can handle IO, but C++ (and Java!) can't. There is no cut and dried answer. At some early point, the developers of C decided, for example, that IO would be relegated to the library. And then designed the language in such a way that this would be possible (e.g. in C, varargs, conversions between pointers and pointer arithmetic, etc.). Similarly, C++ has generally made the choice to enrich the language in such a way as to permit a library solution, rather than solve the problem directly. There are, of course, limits to what one can do in this direction, and at least some of the proposals for the next version of the standard---things like threading, garbage collection or concepts---require or benefit from some help from the compiler. In general, as a user, what interests me is how efficiently the language supports my application. Whether that support comes in the form of language features, standard library, or even, at least to some degree, third party libraries, is really irrelevant. (Considering support from third party libraries is somewhat arguable; the fact that Java has Swing, where as C++ depends on third party libraries for GUI support, is a definite disadvantage for C++ if your application needs GUI support.) -- James Kanze (Gabi Software) email: james.kanze (AT) gmail (DOT) 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! ] Back to top Bo Persson Guest Posted: Mon Nov 20, 2006 10:10 am    Post subject: Re: The D Programming Language Walter Bright wrote: Quote: Bo Persson wrote: We have tried that before, but as the designer of the D language believes that we should compare core language only, and that features already implemented in the C++ library doesn't count, this avenue hasn't been very fruitful. 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. 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. The D language requires compiler support for strings, the C++ language allows it. That doesn't mean that there are no strings in C++. Quote: 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. Quote: 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. I respect your opinion, but just don't find it interesting to discuss languages from that point of view. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Walter Bright Guest Posted: Mon Nov 20, 2006 10:10 am    Post subject: Re: The D Programming Language Seungbeom Kim wrote: Quote: 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. Quote: Thus it is important for the core language to have enough flexibility and power to accommodate good library designs. Sure, we agree on that. Quote: 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. Quote: 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. Quote: 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! ] Back to top AJ Guest Posted: Mon Nov 20, 2006 10:10 am    Post subject: Re: The D Programming Language Hi there, Seungbeom Kim wrote: <snip> Quote: 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. Here's one example: Multi-threading and thread safety. For 1: In D, this is achieved in a super-clean and succinct manner: Adding a synchronized keyword. 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. 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. 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. On the other hand, D isn't available by default almost anywhere, whereas C++ is, so that's one disadvantage. However, wasn't this the case with C++ vs. C too, at some point? 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. Quote: 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." :) Cheers, -Al. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Walter Bright Guest Posted: Tue Nov 21, 2006 1:42 am    Post subject: Re: The D Programming Language Bo Persson wrote: Quote: 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). Quote: 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. Quote: 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? Quote: 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? Quote: 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! ] Back to top James Kanze Guest Posted: Tue Nov 21, 2006 1:51 am    Post subject: Re: The D Programming Language AJ wrote: Quote: 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. Quote: 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. Quote: 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. Quote: 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). Quote: 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. Quote: 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.) Quote: 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. Quote: 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. Quote: 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. Quote: 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 (AT) gmail (DOT) 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! ] Back to top James Kanze Guest Posted: Tue Nov 21, 2006 1:51 am    Post subject: Re: The D Programming Language Walter Bright wrote: Quote: Seungbeom Kim wrote: Walter Bright wrote: [...] Quote: 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. You're missing his point. Sure you can do complex numbers in a library, in pre-C99 C. But the results will not be anywhere near as convivial as the language support for them in Fortran. One of the design goals of C++, as I understand it, is precisely that you should be able to implement a library solution which is as convivial and as performant as the language support in Fortran. Rather than add a complex type to the language, Stroustrup added operator overloading. The result is that complex can be effectively relegated to the library, at no real cost. (In theory, anyway. Depending on the compiler, the fact that function calls etc. are involved may reduce optimization.) Quote: 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. But... From that point of view, the fact that some things can be effectively relegated to the library, rather than be implemented in the core langage, would be a symptom of an advantage in the language. (Supposing, of course, that the functionality in the two cases was equivalent.) -- James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) 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! ] Back to top Francis Glassborow Guest Posted: Tue Nov 21, 2006 1:56 am    Post subject: Re: The D Programming Language In article <tsednYHu551Nqf3YnZ2dnUVZ_v-dnZ2d (AT) comcast (DOT) com>, AJ <two (AT) haik (DOT) us> writes Quote: It would also be unfair to consider library support as good as core language support for (at least) two reasons: 1) Syntax. 2) Convenience. But there is no requirement that parts of the Standard Library MUST be implemented in compilable C++. An implementation is generally free to do better than that. The difference is that core features must be supported directly by every platform (well even here there is room for an implementation to provide a feature with cumbersome code if nothing else is possible) One reason that there are so many constraints on what you are allowed to do in the std namespace is exactly that implementations are free to provide standard library features in any way consistent with the specifications. One example is valarray where the intent was that implementations for hardware with array-processors could provide sophisticated and efficient implementations while less powerful hardware could still provide an implementation. And, yes, I know that valarray has not lived up to expectations but I also know that the problem was withdrawal by the companies producing big number-crunching hardware from language development (both C and C++) during the later part of the 90s) -- 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! ] Back to top Frederick Gotham Guest Posted: Tue Nov 21, 2006 1:58 am    Post subject: Re: The D Programming Language Walter Bright: Quote: 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! ] Back to top AJ Guest Posted: Tue Nov 21, 2006 8:05 am    Post subject: Re: The D Programming Language Hi there, Frederick Gotham wrote: Quote: 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. My knowledge of C++ compiler internals is not very extensive. However, I still find this "wild-west" mentality kind of detrimental for the end-user. Can someone with a C++ implementation background actually confirm that the great hassle that is UB significantly benefits the implementation? That is to say, that the benefit outweighs its cost? I think that a lot of UB doesn't actually help anyone and is just there out of carelessness, or laziness. Perhaps just for C compat? If so, this simply passes the buck to C. It'd also be interesting to hear from people familiar with the upcoming C++ standard about whether UB is being mitigated in any way. Thanks! -Al. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3 ... 13, 14, 15  Next Page 1 of 15   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.