Re: Whose idea to make it a function?
Greg Herlihy wrote:
kanze wrote:
Greg Herlihy wrote:
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.
The fact that numeric limits are also available as macros in
<cfloat> rules out the possibility of numeric_limits::max()
performing any kind of runtime check.
Not really. The fact that the C standard says that the macros
must be constant expressions does restrict this possibility,
however. (I don't know why, but I was under the impression that
this was not a requirement in C.) The fact that things like
numeric_limits::digits is not a function also pretty much
restrict this possibility.
The fact remains that real machines can change their floating
point representation dynamically, or at least at start-up. How
the C++ implementation copes with the fact that
std::numeric_limits<double>::radix may be either 2 or 16,
according to some bit in a mode register, I don't know, but this
is the actual case for modern IBM mainframes. (The obvious
solution is to just ignore it, and pretend that the processors
work as they always have, and don't support IEEE in option.)
There is only ony limit per program per type. So how could
DBL_MAX and std::numeric_limits<double>::max() ever disagree
without at least one of them being incorrect?
#define DBL_MAX (std::numeric_limits<double>::max())
(That's obviously not a legal definition in C.)
A numeric limit is a superlative property of a specific type
and of a specific program - the greatest (or least) value of
that type encountered in any of the program's possible
execution states.
I spelled out some of the potential problems in another program.
Changing floating point formats in the middle of program
execution is definitly not for the faint of heart. Deciding
which floating point representation to use at program start-up,
say depending on an environment variable, does seem reasonable
to me, at least in certain contexts. Without the explicit
restrictions that certain values (e.g. FLT_RADIX or
std::numeric_limits<float>::radix) must be integral constant
expressions---in the case of FLT_RADIX, usable in an #if, seems
to exclude this, however.
Runtime options simply multiply the number of a program's
execution states, but do not eliminate any that already exist.
True, but certain execution states are not possible. In
particular, for example, on an IBM mainframe, if you are in IBM
native mode, there is no way to represent a floating point value
which would represent the maximum of a IEEE double.
So the only way to change a set of limits for a
program is to change the program itself - and for most
development environments - that means recompilation.
That's not at all true in general. At least at the hardware
level, the limits of an IBM double depend on a bit in a hardware
status word somewhere. (Whether C++ supports such changes is
another question.)
--
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 ]