Re: Compile Time String processing
On Feb 27, 12:23 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
On Feb 26, 9:37 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
Lance Diduck wrote:
What I am not clear on, if FPN's were allows as template non-type
paramters, and by extension in compile time expressions, how would
something like this work:
template <float F> struct foo {enum{val=0}; };
template <>struct foo<3.3333333333333>{enum{val=1}; };
template <>struct foo<3+1.0/3>{enum{val=2};};
typedef foo<10.0/3> bar;
It seems to me that the value of bar::val is indeterminate.
It's not any less portable than:
if (x == 3.3333333333) ...
but that's allowed.
The question is whether foo<3.3333333333> and foo<3.3333333332>
are the same type or not. When templates were being adopted
back in the 1990's, the committee didn't have any real answer to
this: is it acceptable to leave it unspecified, or must it be
implementation defined, or even must it be specified by the
standard. In the end, they decided not to allow it, rather than
risk doing the wrong thing.
Now we have implementation experience with floating arguments; they
work, are used, and are useful.
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. In my own work,
I've never needed floating point parameters for templates, so
I'm not going to spearhead any movement to add them, but if
some people find that they might be useful, we certainly have
more experience than we had in 1995 to base the decision on.
None of these problems have
materialized,
Normal, since we didn't have the feature:-).
Seriously, I think that there are problems, but I think that
they're probably of the "user beware" type (and if we banned
those, we wouldn't support floating point at all). Some things
that we do with floating point template parameters will have
surprising results, and some won't be portable, but that's the
case of all floating point, already. There will be some
problems specifying what is required, and what isn't, because
C++ supports cross-compilers, and currently doesn't require full
emulation of the target platform's floating point in the
compiler; this means that something like "0.3333333 == 1.0/3.0"
might evaluate true at runtime, but false when evaluated by the
compiler (and thus, true in an if statement, but with
"0.3333333" and "1.0/3.0" resulting in different types when
instantiating a template).
I don't think that any of these are necessarily insurmountable
problems, but they do have to be addressed. Note that this is
place D could be of help. 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)? Or simply, for that
matter, how useful is it really? Are there (real) problems
which it solves, or does it just give a feeling of completeness
(and orthogonality), without really being used?
When defining a standard, this is
more or less what you have to do. It's easy to add a feature,
once you know what it should do, but it's almost impossible to
remove one, or even change it, if you make the wrong choice.
Should have thought of that with exported templates <g>.
And a lot of library issues:-). I think there's a saying about
once burned, twice wary, that's applicable here. Just because
we made a mistake in the past is no reason to make the same
mistake in the future. (The problem is, of course, that without
something like export, you can't use templates at the
application level in large projects.)
I think the
lesson is not to avoid new things, but to try implementing them before
welding them in to the standard.
In general, the rule is experiment first, then standardize what
works. In practice, there is a fine line: if the experiment
works, it will be emulated (in incompatible ways) in other
implementations, and once incompatible implementations are
widespread, standardization becomes difficult as well. Still,
it's easier for an experimental implementation to correct a flaw
than when it is fixed in the stone of the standard.
This makes the D programming language, which is very close to
C++, on topic and relevant as working examples of some
proposed new features.
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++.
(The way floating point is specified in C/C++, something like
the above could even depend on the level of optimization. And
yes, this affects the if as well---I've had examples of code
compiled with g++ where the results of something like the if
changed depending on the optimization level I used.)
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?
--
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! ]