The D Programming Language
in [C++]
|
From: Walter Bright on 27 Nov 2006 21:32 Peter Dimov wrote: > Walter Bright wrote: >> James Kanze wrote: >>> Walter Bright wrote: >>>> The C++98 Standard defines many operations on complex as taking an >>>> argument of type complex&. That means taking a pointer to it, which puts >>>> the kibosh on enregistering complex. >>> In a naive implementation. >> That would include 100% of current implementations. DMC++ generates: _main: sub ESP,01Ch fld qword ptr FLAT:_DATA[00h] fstp qword ptr 8[ESP] call near ptr _rand mov [ESP],EAX fild dword ptr [ESP] fadd qword ptr 8[ESP] sub ESP,8 fstcw 4[ESP] fldcw FLAT:_DATA[08h] fistp dword ptr [ESP] fldcw 4[ESP] pop EAX add ESP,020h ret Not essentially different. Note that neither compiler put complex numbers into a register pair. -- [ 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 27 Nov 2006 21:33 * Mirek Fidler: >> * [Unattributed quote, then] > I am afraid my response might be considered a little bit offending, > > void main() > > mov %eax,%ebx Indeed -- the combined effect of unattributed quoting, void main, and machine code, might be considered a little bit offending by some readers of clc++m. The FAQ contains good guidelines for first-time posters. First time posters: see the link in the clc++m banner at the end of this (and every) article. -- 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: Peter Dimov on 28 Nov 2006 10:55 Walter Bright wrote: > Peter Dimov wrote: > > Walter Bright wrote: > >> Peter Dimov wrote: > >>> In theory, they ought to fail. In practice, most of them work just > >>> fine. That's the beauty of UTF-8. In-place character manipulation > >>> doesn't work in general anyway, even for an ordinary single-byte > >>> encoding. > >> Having them 'mostly' work isn't good enough. Searching doesn't work, for > >> example. > > > > I believe that it does. > > Nope: > > size_type find (charT c, size_type pos = 0) const; > > What if c isn't ASCII? Then (a) it doesn't work, and (b) it's quite likely that the caller has no idea what he's doing, since he's not passing a character. Integers outside the ASCII range cannot be interpreted as characters without information for the encoding that's been used. As I said, the libraries fail in theory, but work in practice, since delimiters are ASCII characters. That's been my experience, at least. I have successfully passed UTF-8 strings through legacy code and they emerge unscathed at the other end. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nemanja Trifunovic on 28 Nov 2006 11:07 > > Third party users of std::string would assume (and correctly so, > according to the standard) that there is a one-to-one correspondence > between characters and string elements. I don't know about the standard ("The C++ Standard Library" 14.1.1 mentiones multibyte vs wide strings), but in practice that assumption is just silly unless the third party library is explicitely restricted to work with ASCII only. In general, multibyte strings (SHIFT_JIS, for instance) are often stored in std::string, or char[] There isn't with UTF-8. > Functions like strchr, which take a *character* (not a string) to search > for, will fail. The design of strchr is simply wrong for UTF-8. > If a third party user uses strchr to search for an ASCII character within an utf-8 encoded string, it will work fine. If he wants to search for "\xd1\x9a", he needs to use strstr - as simple as that. The only scenario where the search is going to fail is if a user tries something like strchr(str, 0x45a); when searching for cyrillic "nje" within an utf-8 encoded string, but I've never seen anybody doing such a thing. C and C++ programmers are aware that such functions search for "bytes", not "characters". -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 28 Nov 2006 11:00
Walter Bright wrote: > Peter Dimov wrote: > > Walter Bright wrote: > >> James Kanze wrote: > >>> Walter Bright wrote: > >>>> The C++98 Standard defines many operations on complex as taking an > >>>> argument of type complex&. That means taking a pointer to it, which > puts > >>>> the kibosh on enregistering complex. > >>> In a naive implementation. > >> That would include 100% of current implementations. > > DMC++ generates: > > _main: > sub ESP,01Ch > fld qword ptr FLAT:_DATA[00h] > fstp qword ptr 8[ESP] > call near ptr _rand > mov [ESP],EAX > fild dword ptr [ESP] > fadd qword ptr 8[ESP] > sub ESP,8 > fstcw 4[ESP] > fldcw FLAT:_DATA[08h] > fistp dword ptr [ESP] > fldcw 4[ESP] > pop EAX > add ESP,020h > ret > > Not essentially different. Note that neither compiler put complex > numbers into a register pair. Given that both compilers optimized out the imaginary part completely, that neither allocated a complex<> anywhere in memory, and that the x87 FPU doesn't quite have a concept of a register pair, I'm really not sure what you mean. Can you give the D output of the program so that we can see what a real compiler should do? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |