Re: Compile Time String processing
On Feb 27, 11:30 pm, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
[...]
D implementation floating point requirements are:
1) It be IEEE 754 compliant
Which means that it is largely irrelevant with regards to C++
for anything concerning floating point. I can understand the
motivation for such a decision, but it is not the decision of
C++, and I don't forsee it being the decision of C++ anytime in
the immediate future.
[...]
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.
OK. Now you have made a statement concerning concrete
statement about use cases, based (I hope) on real experience.
As I think I mentionned, the problem (potential problem, at
least) is that in the case of if, I have alternatives, operators
like < or <=, or I can modify it to check for proximity, or
whatever my algorithm entails. Template types are based on
strict equality, so I don't have these alternatives.
Does that make floating point arguments for templates unusable?
I don't know. I do think that there is, or at least was, enough
doubt to consider that the committee did the right thing, in the
mid 1990's, in not supporting them.
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.
I'm not trying to underrate it; I think it's important as well.
I'm just pointing out that it's not the only thing which has to
be considered. (There's also the problem that the behavior of
integral types and floating point types isn't orthogonal to
begin with.)
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).
Now there's something we can agree on:-).
C++ has a lot of problems with orthogonality, and the C++ templates are
a big part of that.
I'd say that the biggest problem is arrays, which don't behave
like any of the other types.
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
Not totally for the last. But above all, I'd add a
meta-philosophy: pragmatism. C++ has always been about
something that works, rather than elegance.
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).
The first two points are interesting. I use garbage collection
with C++, at least in new projects. And while I think that D
has had a positive influence in this regard, the movement to add
garbage collection started long before D showed up. And as for
the inheritance model, I find it easier to do OO type
inheritance in C++ than in Java; I find Java's distinction into
two types of inheritance very artificial and limiting. (When I
did do a large application in Java, we made very little use of
interface---our "interfaces" were what Java calls abstract
classes, with all of the public functions declared final. Very
much like I do in C++.)
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 ==.
OK. I can accept that.
--
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! ]