The D Programming Language
in [C++]
|
From: Walter Bright on 29 Nov 2006 04:07 Peter Dimov wrote: > So your point is that having complex as a built-in allows you to define > an ABI that returns it in ST0:ST1 One of the advantages, yes. > (but you still pass it on the stack.) True. It would be sweet if it passed it in a register pair, too. But that's a weakness in the compiler, not the language. > I admit that it's unlikely for any ABI to return UDTs in registers. > > It's hard for me to imagine a situation where this could make a > substantial difference. For it to matter, the function must not be > inlined but must still be short enough and its results must not be > stored into memory (to call another such function, perhaps) but used > for a computation. I could be wrong. It would have the same (rather substantial) advantages that enregistering other variables give. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nevin :-] Liber on 29 Nov 2006 07:21 In article <5OmdndX6x_MNHPHYnZ2dnUVZ_oqdnZ2d(a)comcast.com>, Walter Bright <walter(a)digitalmars-nospamm.com> wrote: > Here's what Digital Mars C++ does, which implements C99 complex numbers: > > ------------------ program ------------------ > #include <complex.h> > > complex long double f( complex long double c ) > { > return c; > } > ------------------- asm --------------------------- > ?f@@YA_W_W@Z: > fld tbyte ptr 4[ESP] > fld tbyte ptr 0Eh[ESP] > ret > -------------------------------------------------- > > Note that even though Digital Mars C++ implements complex as a native > type (per C99), this does NOT prevent it from implementing C++98 complex: > > -------------------- program ---------------------- > #include <complex> > > std::complex<long double> f( std::complex<long double> c ) > { > return c; > } > -------------------- asm -------------------------- > ?f@@YA?AU?$complex(a)std@_Z(a)std@@U12@@Z: > fld tbyte ptr 8[ESP] > mov EAX,4[ESP] > fld tbyte ptr 012h[ESP] > fxch ST1 > fstp tbyte ptr [EAX] > fstp tbyte ptr 0Ah[EAX] > ret > ---------------------------------------------------- So what is it about C++ that is stopping you from applying the optimization you use for the intrinsic complex to std::complex (and then, in general, to objects that have a similar form to std::complex)? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nemanja Trifunovic on 29 Nov 2006 11:36 Walter Bright wrote: > I agree, but it just reiterates my point that std::string cannot be > extended to support Unicode and do Unicode things with it. A new type > has to be created. > Again, that depends on what you mean by "extend". std::string can be easily used with a 3rd party library like UTF-8 CPP to handle utf-8 encoded strings. Does it make std::string a first-class utf-8 enabled type? No, of course not. But it does the job, and it is already out there, unlike the C++0x utf-8 type which may or may be available to us mortals in 10 years. Slightly off topic: one advantage of D over C++ is that it is *not* standardized. C++ was doing much better when it was developed by a single person, IMHO. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Lourens Veen on 29 Nov 2006 15:38 Nemanja Trifunovic wrote: > > Walter Bright wrote: >> I agree, but it just reiterates my point that std::string cannot be >> extended to support Unicode and do Unicode things with it. A new >> type has to be created. >> > > Again, that depends on what you mean by "extend". std::string can be > easily used with a 3rd party library like UTF-8 CPP to handle utf-8 > encoded strings. Does it make std::string a first-class utf-8 > enabled type? No, of course not. But it does the job, and it is > already out there, unlike the C++0x utf-8 type which may or may be > available to us mortals in 10 years. But the UTF-8 CPP library could just as well have been written if std::string was a built-in type rather than part of the standard library. This whole discussion came about because there was a claim that having types in the library is better, because the user can extend them. If the types are built-in, then the compiler needs to be changed, which the user generally can't or won't do. Walters point, if I understand him correctly, is that the abstraction underlying the type is often the problem in creating the extension. In this particular case, the underlying model of std::string is that of a sequence of fixed-size chars. UTF-8 does not fit that model, since one letter may take up more than one char. So, even though std::string is a library type, we still can not easily extend it to support UTF-8. As I posted earlier in this thread, std::wstring, which was designed to support UNICODE, could probably be implemented to use UTF-8 internally to save storage space, while keeping the same outward interface. The underlying model for std::wstring is that of a sequence of UNICODE characters, and a UTF-8 string does fit that abstraction. Lourens -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 29 Nov 2006 15:42
Andrei Alexandrescu (See Website For Email) wrote: > James Kanze wrote: > >> Andrei Alexandrescu (See Website For Email) wrote: >> >>> That's simply wrong. Java does not check thread safety >>> statically, yet is able to define behavior of even incorrect >>> multithreaded code. >> >> >> >> Writing to a double while another thread is reading it is >> undefined behavior in Java. > > > I've ran a number of searches for that ("java undefined behavior > double", "java undefined behavior threads double" etc.), no avail. I'd > be glad if you provided a reference. Thanks! > > Maybe (also) we're using slightly different definitions for undefined > behavior? I am still waiting for a response on this issue, or a retraction of the initial statement. This is relevant to C++ in the following way. When the C++ thread standardization process started, it was assumed that the Java memory model ensures well-defined programs even when they do have races. The committee decided (correctly IMHO) to depart from that model for efficiency reasons, leaving the behavior of certain programs undefined. My current understanding is that races on longs and doubles could produce undefined longs and doubles being read, but not undefined programs. Now, if Java does allow programs with undefined behavior, that would quite change the "golden standards" in terms of safety. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |