The D Programming Language
in [C++]
|
From: Francis Glassborow on 20 Nov 2006 14:56 In article <tsednYHu551Nqf3YnZ2dnUVZ_v-dnZ2d(a)comcast.com>, 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. 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! ]
From: James Kanze on 20 Nov 2006 14:51 Walter Bright wrote: > Seungbeom Kim wrote: > > Walter Bright wrote: [...] > > 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.) > > 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(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: AJ on 20 Nov 2006 21:05 Hi there, Frederick Gotham wrote: > 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! ]
From: Denise Kleingeist on 20 Nov 2006 21:08 Hello Bo! Bo Persson wrote: > 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. Its somewhat out of context but I want to mention that variadic template arguments are at the very top of my wishlist! Followed by a huge gap and then something similar to reflection in some other languages. Variadic templates allow proper implementation of many of the core features in generic code, like tuples or functions with arbitrary arguments. Given that generic adapters are used in many places, makes variadic templates (or something which does something similar to them) crucial. It avoids a lot of typing and/or some form of preprocessor coping with this repetition. Good luck, Denise! -- [ 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 21:08
James Kanze wrote: > 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.) If your point is that std::complex is just as good as native complex, consider the following: 1) Digital Mars C and D implement complex natively, and complex function return values are in the floating point register pair ST1,ST0. I don't know of any C++ compiler that does that. It's certainly more efficient. Native support also means the compiler can easily enregister the complex numbers within the function. 2) std::complex has no way to produce a complex literal. So, you have to write: complex<double>(6,7) instead of: 6+7i // D programming 3) Error messages involving native types tend to be much more lucid than error messages on misuse of library code. 4) There is much better potential for core native type exploitation of mathematical identities and constant folding than there is for library types where meaning must be deduced. 5) Lack of a separate imaginary type leads to problems such as identified by Professor W. Kahan: "A streamline goes astray when the complex functions SQRT and LOG are implemented, as is necessary in Fortran and in libraries currently distributed with C/C++ compilers, in a way that disregards the sign of 0.0 in IEEE 754 arithmetic and consequently violates identities like SQRT( CONJ( Z ) ) = CONJ( SQRT( Z ) ) and LOG( CONJ( Z ) ) = CONJ( LOG( Z ) ) whenever the COMPLEX variable Z takes negative real values. Such anomalies are unavoidable if Complex Arithmetic operates on pairs (x, y) instead of notional sums x + i*y of real and imaginary variables. The language of pairs is incorrect for Complex Arithmetic; it needs the Imaginary type." So, why isn't there much of any outcry about these problems with std::complex? My theory is that few use C++ for serious numerical computing, derived from the observation that popular and widely used C++ compilers have dropped support for extended doubles (80 bit floating point) without pushback from the users. I used to do numerical analysis (calculating stress, inertia, dynamic response, etc.), and having 80 bits available is a big deal. > 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.) The problem is, the functionality is not equivalent. If it was, why are there proposals to, for example, add new basic types to core C++ to support UTF strings? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |