Re: Compile Time String processing
James Kanze wrote:
Now we have some experience with templates in general. Don't
forget that when the standard was being formulated, we didn't
have any real experience in templates at all.
And that shows. C++ template metaprogramming is all about doing things
that were, rather obviously, never thought of when the template facility
was designed. C++ template metaprogramming was discovered, rather than
designed. It's like using a belt buckle as a screwdriver.
I'm not being critical of C++'s designers for this - it's unreasonable
to expect anyone to be so prescient. But now that we know about template
metaprogramming, we can purposely design a system to support it.
What does D do in the case of cross
compilation, for example: does it just accept that equality of
types doesn't correspond to the equality of run-time values (and
what are the consequences in user code), or does it require full
emulation of the target floating point (and what is the
implementation effort which this implies)?
D implementation floating point requirements are:
1) It be IEEE 754 compliant
2) It must be done at at least the minimum precision specified by the type
3) It optionally can be done at arbitrarily higher precision than is
available at runtime
4) Runtime precision can be increased for intermediate values
In other words, the programmer should write floating point code in such
a manner that if the precision were to be increased, the algorithm would
not malfunction. It's analogous to designing digital electronics
circuits assuming maximum propagation delays, and that substitution of
faster parts wouldn't break the circuit. (Because parts get faster over
time, not slower.)
This also means that trying to specialize templates on values subject to
roundoff should raise an eyebrow just as:
if (x == 10.7/3.6)
should.
Or simply, for that
matter, how useful is it really? Are there (real) problems
which it solves,
Yes. D programming is used by physicists for numerical work, and they
use it (and asked for it). In the past I've had to write programs that
generated static array tables of floating point values to be #include'd
as C++ source code, so yes, that could have been done at compile time
instead.
or does it just give a feeling of completeness
(and orthogonality), without really being used?
Orthogonality shouldn't be underrated. It gives the language the feeling
of solidarity and consistency, rather than being a bag of hacks and
kludges. It reduces the effort to learn a language. Perl is a language
without orthogonality, and look at all the trouble that has caused (and
how it created an opportunity for Ruby).
C++ has a lot of problems with orthogonality, and the C++ templates are
a big part of that.
I ain't smart enough to anticipate all the uses a feature can be put to.
I'm consistently surprised at the creative uses put to things that were
just put in for consistency and orthogonality. That certainly happened
with template string literals - it never occurred to me one could use
that to build a compile-time regex compiler!
My question, in part, is just how close is it. Many of the
things you say about it suggest to me that it is closer to Java
than to C++. And for some things, Java is a radically different
language, with only the look and feel of C++.
A language's philosophy ultimately affects what it is. These are the
philosophies of the 3 languages as I interpret them:
C++:
1) A better C
2) Only pay for what you use (runtime efficiency trumps)
3) The programmer is King and in charge
4) Legacy code must not be broken
5) If there's any way something could be done in a library, that is the
preferred solution
6) Implementation difficulties are irrelevant
What makes Java a radically different language is its radically
different underlying philosophy:
1) Provide an abstract machine that completely hides the real machine
2) Byte code interpreter semantics must not change
3) The machine must be protected from the programmer
4) The JVM is King and in charge
5) OOP hammers all nails
6) Get rid of the hard features of C++
D's philosophy is much closer to C++'s, hence it is far closer to C++
than to Java:
1) It should take its design cues from C++
2) The programmer is King and in charge
3) The natural way to do something should also be the safe and correct way
4) Maintain C ABI compatibility
5) It's ok to be source incompatible with C++ if the reason is sound
6) Programmer efficiency is as important as runtime efficiency
7) Fix the hard features of C++
You might get the impression that D is like Java because D has garbage
collection and a similar OOP inheritance model, but that's about where
the similarity ends. D is nothing like Java (aside from their common C++
heritage).
People who deal with floating point code quickly learn to come to terms
with the a==b problem,
I don't know about that. It seems to be a perpetual source of
problems (probably because it doesn't have a simple solution
which can be explained in a few words).
and are able to transfer that knowledge to
working with floating point template arguments.
Do you have any actual statistics, or just a gut feeling?
My knowledge comes from working with people who use floating point
templates. None of them have ever wondered about the issue with
templates, after they understood the issues with plain old operator ==.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]