From: Mirek Fidler on
Well, my main compaint about the D language is that Walter wastes his
time on this project and therefore has no left for makeing his C++
compiler more usable (standard compliant, more platforms). What a pity,
we might have choice between GCC and DMC....

Mirek


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: David Abrahams on
AJ <two(a)haik.us> writes:

> It would also be unfair to consider library support as good as core
> language support for (at least) two reasons:
>
> 1) Syntax.
> 2) Convenience.

Not necessarily. My ideal language would allow me to create library
support whose syntax and convenience are, in most cases, just as good
as that of the best possible core-language design.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
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

> Furthermore, what is the relevance to library versus built-in?

None. The relevance is to the lack of an imaginary type for C++ (library
or built-in) and what such lack says about serious numerical analysis use.

Note that C99 does address this and includes an imaginary type. So does D.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
James Kanze wrote:
> But the argument that C++ doesn't have a string type is false.
> It does.

I didn't argue C++ didn't have a string type. I argued that:

1) library features are not part of the core language.

2) C++ (and D) do not have good enough core features to be able to
create a library string (and vector, complex and associative arrays)
that are good enough to compete with core support for such.

3) String, complex, vector and associative arrays are ubiquitous enough
that the extra goodies one can get with a core feature make them
worthwhile to put in the core language.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Bo Persson wrote:
> Requiring compiler support doesn't make a feature clean, it makes it dirty.

I tend to feel that what makes a language dirty is when it's loaded with
special cases and arcane rules. A clean language is not necessarily one
with a small number of features, it is one with features that are
orthogonal yet fit together in a predictable and sensible manner.

> I believe that's where James and I disagree with Walter.
> If you have a core language support that allows std::string to be
> efficiently implemented as a library, that means that other similar classes
> can be efficiently implemented as well. By someone other than the compiler
> writer.
>
> The fact that it can be done as a library only, with no specific magic,
> actually shows that the language is stronger, not weaker.

D can, as well as C++ can, create library defined strings, vectors, etc.
I get the impression you feel that D somehow sacrificed the ability to
create user defined types by adding core support for arrays and strings.


> The fact that Walter designs and implements his own language,
> puts him in a
> different position than most of us. Perhaps that influences his point of
> view? Or maybe his views is the reason for doing it?

Actually, it was using languages that did support strings and arrays
much better than C++ that led me to want much better than what could be
done with a library. Maybe it's a coincidence that such languages are
almost always considered to be easier to learn, use and more productive
to program in than C++. Strings and arrays are ubiquitously used, so
even small improvements in their usability can pay big dividends in the
long run.


> 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.

But I do have a couple challenges for you <g>.

1) Extend std::string to support UTF-8.

2) Extend std::string to support strings with embedded 0's.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]