Re: Whose idea to make it a function?
Greg Herlihy wrote:
Frederick Gotham wrote:
"Bo Persson" posted:
Because floating point values are not compile time
constants. (Think cross-compiler).
This is, in fact, false. A floating point value can be a
constant, although you can't do as much with it as you can with
an integral constant. A floating point constant can even appear
in an integral constant expression, if (and only if) it is
immediately converted to an integral type.
Hmm... the following snippet suggests otherwise:
int main()
{
char *p = 25235.25225 ? 0 : 1;
Correct. This is legal because the floating point constant is
immediately converted to bool, which is an itegral type.
}
The above program shows that a floating point literal is a
compile-time constant - but that fact was not being
questioned. The challenge was to replace a floating point
literal with a symbolic constant - and without the program
being at all affected by the change.
So revising the above program to:
const double kConstDouble = 25235.25225;
int main()
{
char *p = kConstDouble ? 0 : 1; // error: invalid conversion
}
is a better test.
Except that it's not really relevant. The rules for floating
point constants are different than those for integral constants;
in particular, a floating point value can appear in an integral
expression only if 1) it is a literal and 2) it is converted to
an integral type. In the original example, both conditions
held; here, one has been violated.
And even though this program's logic appears to be unchanged
from the original, it is no longer the same program. This
revised version no compiles successfully because 1 is not a
type of pointer (whereas the original program simply
eliminated the false case of the conditional expression
altogether.)
In essence there is really no difference in efficiency whether
numeric_limits<double> is declared as a constant and as an
inline function - because neither is a constant expression.
Neither is an integral constant expression. The first is still
a constant expression.
And given that (in general) methods should be favored over
direct access to data (to promote encapsulation), there is a
good argument for numeric_limit::max's current implementation.
The problem is that the same interface is imposed on
std::numeric_limit<char>::max. And there are a lot of things
you could do with that if it weren't a function.
The reason std::numeric_limit<>::max is a function is simple:
there are implementations where it is impossible to determine
the value until runtime---implementations where runtime options
may affect it.
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]