Re: Compile Time String processing
James Kanze wrote:
On Feb 27, 11:30 pm, Walter Bright <wal...@digitalmars-nospamm.com>
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.
IEEE 754 is one way of doing floating point - there is nothing about it
that either aids or retards having floating point template args. Worst
case, you'd have to write an emulator, and as I wrote before, that isn't
a big problem.
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?
Far from it - consider a template to compute the square root:
template sqrt(real x, real root = x/2, int ntries = 0)
{
static if (ntries == 5)
// precision doubles with each iteration,
// 5 should be enough
const sqrt = root;
else static if (root * root - x == 0)
const sqrt = root; // exact match
else
// iterate again
const sqrt = sqrt!(x, (root+x/root)/2, ntries+1);
}
void main()
{
real x = sqrt!(2);
writefln("%.20g", x); // 1.4142135623730950487
}
Not only does it use exact matching of floating point values, it
*relies* on it in a portable manner.
A language's philosophy ultimately affects what it is. These are the
philosophies of the 3 languages as I interpret them:
C++:
[...]
6) Implementation difficulties are irrelevant
Not totally for the last.
I added that because in the early days of the C++ committee, that
philosophy was expressed to me several times by various committee
members. I predicted that trouble would result from it and it did - over
a decade of persistently incompatible, incomplete implementations, as
well as the shrinkage in the number of several C++ vendors.
But above all, I'd add a
meta-philosophy: pragmatism. C++ has always been about
something that works, rather than elegance.
I tend to agree with that. C++ seems absent the religion that infects
other languages, like "everything must be an object".
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.
I know. I've found serious proposals to add gc to C++ going back to
1995. I wouldn't (and didn't) say that D inspired gc in C++, but it does
add to the pressure.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]