Re: Compile Time String processing
James Kanze wrote:
Since C++ utterly routed and destroyed Modula-2 about 18 years
ago, it'd be hard to get anyone to listen to a spiel about
adopting M2 features :-).
Well, Java adopted some of Modula-3's features, and you
occasionally hear calls for them to be adopted into C++
(finally, for example).
I would hypothesize that the calls for finally are based on experience
with Java, not M3, as Java is a current (not dead) language, and there
are an enormous number of Java programmers used to finally.
I just don't believe you're going to get many people to listen to a
presentation entitled "Features from Modula-3 that should be put in to C++."
(And of course, anyone who's actually
used Modula-2 still misses its modules in C++. Even after 20
years.)
Which again emphasizes my point that M2 is not a compelling example - it
failed for 20 years to even inspire a proposal for C++ modules.
The concept of modules has been around for a long time; Ada's
packages are very similar (and for many applications, Ada is
C++'s only concurrent). And it has been generally recognized
for a long time, even by people who are otherwise very pro-C++,
that textual inclusion is not really a good solution to the
problem; it can, with a lot of care on the part of the user, be
made to work, but that's about all that can be said for it.
I'm not going to suggest that D invented modules, and I'm sorry if I
gave the impression that I thought it did. What I *am* suggesting is
that D features are providing motivation for C++ proposals. In this
case, 20 years go by and modules don't get put in C++, then a few months
after discussing D modules with Daveed, he proposes them for C++. While
Daveed says that D modules didn't inspire him, he did use D modules as
an example to try to motivate others to support C++ modules.
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.
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.
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.
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.
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. 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.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]