Re: Compile Time String processing
On Feb 27, 11:23 pm, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
[...]
As more of a meta-comment: I believe that one of your goals with
regards to D is that the language should be used. If so, then
it is normal, and IMHO necessary, that D doesn't invent totally
new concepts.
There's not much in D that could be called a new concept in programming.
D draws heavily on existing practice in other languages - primarily C++
- but Ruby, Python, Lisp and others are also influential.
I think that's where we agree. If D can lay claim to any
originality, it's in the particular mixture of concepts that it
offers, not in any new concepts. And IMHO, that's a feature, at
least if I want to use the language in production. I want
features which have proven their usefulness elsewhere.
Users need something stable, and to define
something stable that works, you need existing practice---that
people have actual experience with the feature.
How many people have experience with template concepts? Has
anyone even attempted an implementation of it? But concepts
are a sure thing for C++0x.
I think that much of the work on concepts got started because of
weaknesses in a purely library solution, as was tried in Boost.
But I'll admit that I'm not really too up to date on them. And
that I'll a little bit sceptical, precisely because we don't
have real experience.
And I don't
think that D is widespread enough that it can be considered as
having "popularized" anything, either.
I didn't say "popularized", so please do not use quotes to put words in
my mouth.
Sorry. It is more of a meta-comment. I'm trying to put D in
its context. What role does it (or should it) play with regards
to C++.
Given these two points,
I don't think that D can be said to have played a large role in
the evolution of C++.
I didn't say that, either. I said: "A number of D features seem to have
wound up as proposals for C++0x (such as contract programming, utf
strings, modules, etc.)". The advocates of C++ modules and C++ contracts
have used the corresponding D features as motivating examples.
That's not what they say. But as I said elsewhere, it's a data
point.
It's sometimes nice to know that a
feature has been implemented in a language similar to C++, but
that's about it.
There's a lot more to it than that, because you can see the feature in
actual use - how it helps, how it interacts with other features, any
problems, etc.
That's exactly what I mean. I'm not too worried about the
implementability in itself---there are enough implementors on
the committee to take care of that. I am worried about getting
it into the standard in the right form, so that it really is
usable.
The closer the language is to C++, the more *relevant*
this is. There's a world of difference between standardizing something
that's never been done at all, and having actual experience. It's like
saying it would be merely "nice to know" that airplanes fly before
placing an order for 1000 airliners at $50,000,000 each.
And you have to define what is meant by
similar: is the compilation model of D closer to C++ or to Java?
The compilation model is pretty much identical to C++. After all, both D
implementations use an existing C++ optimizer and back end.
That's not what I meant (but I don't really know the right
word). What I was talking about was the fact that you define a
class separately from its member functions; that in most cases,
the member functions aren't even in the same file. When I think
modules, I do still think of Modula-2, and its interface and
implementation sections; if I think of a modern language, I
think Ada, with its package specification and package body.
Somewhere I got the idea that D was like Java; that you defined
the member functions in the class definition. If that's the
case, I'm not sure that its concept of modules would be
applicable to C++.
--
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! ]