The D Programming Language
in [C++]
|
From: Walter Bright on 21 Nov 2006 11:03 Gabriel Dos Reis wrote: > Walter Bright <walter(a)digitalmars-nospamm.com> writes: > | 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. > Let me see if I get it right. You have observed (from data you > collected) that widely used C++ compilers have dropped support for > extended doubles (80 bit floating point) without pushback from the > users. Therefore it logically follows that few use C++ for serious > numerical computing. I know people who do numerical analysis who do not understand the problems with creeping roundoff error. I wouldn't call them serious, because they don't recognize when their answers are way off. They refuse to believe that a .0000001% error can rise up to utterly swamp their results. On the other hand, I used to do numerical analysis work (using FORTRAN). If I got the wrong answer, it would put lives at risk (I worked on flight critical airplane control systems) or at the very least cost an awful lot of money. This analysis included things like numerical integration, finite element, and matrix inversion, which are all very, very sensitive to creeping roundoff errors. The easiest way to deal with roundoff errors is to increase the precision. Any compiler that doesn't at least provide the full precision of the underlying hardware cannot be taken seriously as a tool for doing serious numerical analysis. It tells me the compiler vendor has some agenda other than paying attention to the numerics crowd, and I wouldn't use such a tool for serious numerical work. The fact that those compiler shortcomings are rarely mentioned, and are not fixed, tells me that whoever is using them is not serious about numerical work. Wizzy template metaprogramming libraries don't mean jack if your Mars probe fires its retro rockets 10 feet below the surface. Most of what I see about floating point work these days with C++ seems to be about game programming. The focus with that kind of work is speed, speed, speed, not accuracy. Nothing falls out of the sky if your line is a few pixels off. Unlike C++, a conforming D compiler is *required* to provide a type representing the max precision the underlying hardware is capable of. And btw, g++ does offer 80 bit long doubles on the x86. Kudos to the gcc implementors. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Frederick Gotham on 21 Nov 2006 11:05 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. -- Frederick Gotham [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Frederick Gotham on 21 Nov 2006 11:04 Andrei Alexandrescu (See Website For Email): > Ouch. Unless this is a joke, I can only be happy that your opinion isn't > shared by many :o). Why would you think undefined (I think you really > meant "unspecified") behavior is a good thing? Well, if we make it undefined behaviour to cast a random integer value to a "pointer to a double", to store the max value in it, and to increment it, then the implementation doesn't have to worry about what to do in case of: ++( *(double*)RandomInt() = numeric_limits<double>::max() ); -- Frederick Gotham [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 21 Nov 2006 14:51 In article <75ydnaz-Vbll-f_YnZ2dnUVZ_ridnZ2d(a)comcast.com>, AJ <two(a)haik.us> writes >I think I agree, though I also think we need a clear definition of a >"library" and of "core-language" support. It is unclear at this point >whether a library can be "magic" in the sense that it does things a >regular user couldn't. I am struggling to see how things like malloc can be implemented without 'magic'. It is a fundamental principle of the C library, and hence the C++ one that Standard Library elements can be implemented any way the implementor chooses and that includes compiler 'magic.' -- 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 21 Nov 2006 15:37
Walter Bright wrote: [...] > I don't think anyone here is advocating a core language that somehow > prevents powerful libraries from being written. D's core support for > arrays doesn't in the slightest prevent someone from writing a vector > class any more than C++'s core arrays prevent it. There just isn't much > point to writing a vector class in D, since the core arrays are good enough. And there isn't any point to adding a new array type to the C++ core language, because std::vector is good enough. Which may or may not be true, depending on what you are doing, but the point is: in C++, you do have std::vector. It's legitimate to compare it to the core arrays in D, if they serve the same purpose (and even without knowing D, I'd wager that the declaration syntax for multi-dimension arrays is better), but that comparison should be based on actual features (like the declaration syntax), and not whether the support itself is in the core language or in the library. -- 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! ] |