Re: The D Programming Language
Walter Bright wrote:
Bo Persson wrote:
The C++ language defines features that can optionally be implemented as a
library, or built into the compiler. The standard allows, but does not
require, specific compiler support for these features. In my opinion, they
are still part of the language.
Such a design choice means that it combines the worst characteristics of
a core feature (not modifiable/replaceable by the user) with the worst
characteristics of a library feature (poor integration with the language).
It means that you can get the performance from the library type
without actually doing the work necessary to optimize library
types:-).
The D language requires compiler support for strings, the C++ language
allows it. That doesn't mean that there are no strings in C++.
As far as I know, there is no existing C++ compiler that implements
std::string in the compiler. Furthermore, since it is required to be
indistinguishable from a library implementation, it isn't in any useful
sense part of the core language.
C++ does have core strings (char[]) and core arrays (T[]), it's just
that they were abandoned and (unofficially) deprecated rather than fixed.
They are a little bit too broken to be easily fixed.
[...]
Template improvements don't float everyone's boat. What is high on your
core language wish list?
Thread support, garbage collection and modules. All of which
affect the basic definition of the language, and can't be done
in a library at all. (By thread support, I mean things like
redefining sequence points so they have a meaning in a
multithreaded envirionment, and such. I see no problem with the
interface to the various requests being in the library; in fact,
I rather prefer it that way. But parts of the library will
probably need to collaborate with the compiler---which is
nothing new, either, since that's already the case with such
"library" types as type_info.)
But what I think is fruitful to discuss or not only pertains to
what I decide to post - I don't control these discussions. I'm not
a moderator here.
It was I who didn't find it fruitful to compare the languages, when you
concentrate on a core only comparison. Without the string, vector, and
complex classes, C++ admittedly is just half a language.
Strings and arrays (and to a lesser extent complex) are such fundamental
types that relegating them to the library means missing out on the
syntactic and semantic niceties one can get by putting them in the core.
After all, would you want 'int' to be library only, and turn your back
on all the goodies a language can offer through direct support of it?
I think you can find arguments for types like string and arrays.
But that's not the point. If you argue that string's in D are
supperior to string's in C++, that's one thing. And it may even
be that the reason is that string's in C++ aren't a native type.
But the argument that C++ doesn't have a string type is false.
It does. (It actually has two, which is probably a bigger
problem than any problem due to the fact that std::string is
part of the library, and not part of the core language.)
And if the language offered ways to define int as an efficient
library type, I'd be all for it. It doesn't. In the case of
int, I don't think it can---int generally corresponds to a basic
type in hardware. Strings and arrays are a bit less clear. And
about the only real argument I can think of for making complex a
basic type is performance (or the absense of any good
abstraction mechanisms---in Fortran IV, there really wasn't an
alternative).
--
James Kanze (GABI Software) email:james.kanze@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! ]