From: kwikius on 26 Nov 2006 10:39 Walter Bright wrote: > > Similarly, if std::complex were part of the language, as > > _Complex is part of C, we'd be trapped with the language designers' > > mistakes. > > No, you can still create a different class. Nothing at all about > building complex in as a core language would *prevent* you from building > a custom complex class. You would not be any worse off than you would be > with C++ trying to replace the standard complex class. > > > As it is, you're free to write an "imaginary" class that > > works correctly. The language even allows you to make it interoperate > > with the "flawed" implementation of std::complex and the math > > libraries. > > You can do the same in D by creating your own class. What would be good though is if you could create a library class that performed as well as the language type. Why is that not possible. (By resorting to a language type you are admitting it is not possible AFAICS) A 2D 3D point or vector would be much more useful to me than complex numbers and of course I would want both vectors and complex numbers to work with my types, which I will bet the D version wont do. (You can make std::complex work with Quan below academically, but its much less effort to create your own complex) http://quan.sourceforge.net/quan_matters/doc/html/index.html regards Andy Little -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Beliavsky on 26 Nov 2006 10:44 { It seems this sub-thread is moving into the territory of FAQ item 6.5. Responders: please read that FAQ item before responding. <url: http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.5>. -mod } Walter Bright wrote: <snip> > I used to do numerical analysis programs for Boeing, so I have a soft > spot for the topic. C++ (and to a lesser extent C) has historically not > paid much attention to the needs of serious numerical analysts. > Improvements have come, but at a glacial pace, and it seems to meet with > stubborn resistance or just apathy. It even goes in reverse now and then > (such as the dropping of 80 bit support). So the analysts keep on using > FORTRAN, and the FORTRAN compiler people know who pays their bills. > > I'd like to get D to the point where analysts can say: "finally, I can > ditch the old FORTRAN war horse and move on to a modern language that > actually caters to my needs." For that to happen, complex and vector > math support has to be top drawer. What's wrong with C++ complex support > has already been discussed, it isn't all currently fixable using UDT > techniques. If proper vector/matrix math can be done using UDT's, then > it'll go that way in D. If it cannot be, then D is faced with having > inferior support for it, or do it in the core. I can't tell at this > point what will happen there. Fortran 2003 is a modern language. Fortran 90 added free source form, dynamic memory allocation, user-defined types, array operations, and other features. Fortran 2003 added single inheritance, stream I/O, procedure (function) pointers, interoperability with C, and other features http://www.kcl.ac.uk/kis/support/cit/fortran/john_reid_new_2003.pdf . Arguably the language has now added the features of C++ and Matlab most needed by scientific programmers. There are at least 9 Fortran 95 compilers (g95, gfortran, Absoft, Lahey/Fujitsu, IBM, Intel, Pathscale, Portland, SUN), and they are all adding Fortran 2003 features. D has 2 implementations, no standard, fewer numerical libraries, and a much shorter history. I don't think many Fortranners will be moving to D. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 26 Nov 2006 13:48 Walter Bright wrote: > You make a lot of good points. I want to reply to a couple of them. > Francis Glassborow wrote: > > What makes a language popular and widely used? Well why is English the > > commonest second language in the World. It is a terrible language full > > of special cases. > English is a terrible language from an academic point of view. It is, > however, a wonderful language from a practical point of view. English > has, for example, over a million words, far more than any other > language. That makes it the most expressive language. English has no > problem with freely incorporating words from other languages, apparently > to the distress of others <g>. Obviously, you don't know any other language very well. In a certain way, all languages are equal. Anything I can say in English, I can say in French or in German as well. There are cases where one particular language seems to have a particularly appropriate expression, but off hand, I'd say that language was German, more often that French or English, with English coming in last of the three. (And that despite the fact that my mastery of German is considerably less than that of French or English.) As for a million words... I'd say that any language had that many, if you count all of the technical words (e.g. names of diseases, scientific names of plants and animals, ...). On the other hand, I know of no English author who uses anywhere near that many. (I read somewhere that Aldous Huxley used something like 50000 words in his works, and that that was something of a record.) In fact, there's no way you can compare the number of words in two different languages. Is it somehow significant that English has two words, watch and clock, where German normally only uses one (Uhr---but of course, they can distinguish if it is necessary), and French at least four (pendule, horloge, reveil and montre, but of course, you can distinguish in English or German if it is important, even if you don't normally do so)? In fact, English is neither terrible, nor wonderful. It's a language like any other. And the reason it is so widely used has more to do with political, demographical and economical considerations than any intrinsic quality of the language. Similarly, although there are far more significant differences between programming languages, the reason C++ is widespread has more to do with political and economical considerations than with any intrinsic qualities of the language. -- 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: Gabriel Dos Reis on 26 Nov 2006 13:49 Walter Bright <walter(a)digitalmars-nospamm.com> writes: | Peter Dimov wrote: | > Walter Bright wrote: | >> 5) better code generation (like for complex, we can (and do) return them | >> in the FPU registers rather than like a struct) | > | > If you optimize the general case of struct { X x; Y y; }, where X and Y | > fit in a register, you get much better ROI. | | 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. Not really. Compilers are free to do inlining and discover that they don't need the references. And in fact, they do. -- 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: Gabriel Dos Reis on 26 Nov 2006 13:51
Walter Bright <walter(a)digitalmars-nospamm.com> writes: [...] | >> 3) Error messages involving native types tend to be much more lucid than | >> error messages on misuse of library code. | > | > Especially if the type is a template:-). | > | > Again, it's a problem that compiler writers should solve, if | > only because library types aren't going to go away. (It is, I | > think, a more difficult problem than just getting the two | > doubles of a struct into registers.) | | C++ compiler writers haven't solved this problem in the last 20 years of | trying, how long are you willing to wait for it? C++ isn't a new | language. Since solutions to these problems haven't appeared in C++ | compilers yet, perhaps it just isn't practical to solve them in the | compiler. Or maybe simply, it is not near the top their priority list. Where pressed, they have put effort in recognizing some library types. -- 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! ] |