The D Programming Language
in [C++]
|
From: Earl Purple on 21 Nov 2006 20:45 Andrei Alexandrescu (See Website For Email) wrote: > 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. > > 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? > casting a void * to a pointer to a function is undefined behaviour. But dlsym() which is a POSIX function returns a void * which often needs to be cast back to a pointer to a function. It is useful to know therefore that a compiler on a POSIX system can be written to allow the cast to succeed to not break all the current existing code that does this cast, whilst at the same time not enforcing it onto all systems in general where void* might not be big enough to hold a function pointer. (Yes, you can code around that by exporting an instance of a variable rather than a function, assuming your library is written in C++ and not C. Do not forget though that C++ allows linkage with C libraries too). -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gabriel Dos Reis on 21 Nov 2006 20:46 Walter Bright <walter(a)digitalmars-nospamm.com> writes: [...] | > 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. So, the question is: Can there be better library implementations, or can the core language be extended to allow better library implementation? (e.g. allow for literal of user-defined types), or do you think that there are *intrinsinc* reasons why they must be core languages? If yes, could you elaborate on those logical, intrinsinc, reasons? -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach on 21 Nov 2006 20:45 * Walter Bright: > 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 Forgive me if I failed to find the quote you intended in that long document. The closest I found was an assertion: "... anomalies are unavoidable if Complex Arithmetic operates on pairs (x, y) instead of notional sums x + ??y of real and imaginary variables." To my mind that explains nothing, just reasserting the earlier assertion. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 21 Nov 2006 20:47 James Kanze wrote: > Walter Bright wrote: > [...] >> Unlike C++, a conforming D compiler is *required* to provide a type >> representing the max precision the underlying hardware is capable >> of. > > For what definition of "the underlying hardware is capable of"? > With proper software support, the underlying hardware is capable > of just about any precision I care to ask of it. Obviously, > this isn't what you mean, but while I think what you mean may be > obvious on most general purpose machines, I'm not sure that it > is precise enough for a standard. > > The C++ standard, of course, follows the lead of C, and allows > the compiler to use extended precision in intermediate results, > without requiring it. The results can be surprising, to put it > mildly. > >> And btw, g++ does offer 80 bit long doubles on the x86. Kudos >> to the gcc implementors. > > I'm willing to bet that even VC++ uses extended precision on an > x86, even if it won't allow you to declare a variable of that > type. Not doing so slows down the math processor considerably. > Earlier versions of VC++ did save all 80 bits if you used long double variables. Newer versions do not, claiming consistency over all Windows versions (on different hardware). Walter will also have some problems implementing D on 64-bit Windows, where the OS doesn't save the x87 registers on a task switch. Someone decided that it was enough to save the *other* set of floating point registers. Bo Persson -- [ 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 22:37
Bo Persson wrote: > Walter will also have some problems implementing D on 64-bit Windows, where > the OS doesn't save the x87 registers on a task switch. Someone decided that > it was enough to save the *other* set of floating point registers. Microsoft fixed that shortcoming. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |