From: kwikius on
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
{ 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
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
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
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! ]