8853071c   
   From: miles@gnu.org   
      
   Daryle Walker  writes:   
   >> Hmm, I've always wondered:  why do the C++ standards always so oddly   
   >> biased against scalar floating-point types, in that there are various   
   >> places like this where "int" is allowed but not "float" (the biggie, of   
   >> course, being static-const-data-member initialization in C++98)...?   
   >   
   > Cross-compilation.   
   >   
   > Discrete is discrete, so one computer system can always simulate the   
   > "int" types of a different system, even if it has to resort to "bignum"   
   > arithmetic.  Floating-point types are more peculiar.  The compiler's   
   > system's floating point doesn't have to be compatible with the target   
   > system's floating point.   
      
   I'm not sure how that's really related, at least for some cases.   
      
   For instance, what really bugs me is the above-mentioned   
   "inline-initialized static const data members" (e.g. struct s { static   
   const float FUNNY = 3.14;};) .  A compiler clearly has to be handle   
   floating-point well enough to compile normal code, which means it has   
   to _at least_ have some minimal representation of floating-point   
   constants and floating-point constant expressions (even if it's so   
   silly as an ascii copy of the source expression), and that's really   
   all that's needed to support this (“wherever you see "s::f", you may   
   substitute "3.14"”).   
      
   For use with templates (template ...), maybe real   
   compile-time evaluation is needed, but I suspect any decent modern   
   compiler _does_ have an accurate simulation of the target   
   floating-point unit (people _expect_ things like constant folding,   
   after all)....  So it wouldn't seem entirely unreasonable for the   
   standard to require it.   
      
   >> It would surely be very convenient for the programmer if float/double   
   >> were allowed, it would make the language seem more consistent, and I   
   >> can't see that it would present any particular implementation   
   >> difficulties...   
   >   
   > They've started that, as "constexpr" can work with the built-in floating-   
   > point types.   
      
   The silly thing is, they added the constexpr method, so clearly   
   compiler support is now required -- but they didn't lift the previous   
   limitation on initialized static-const members, for which there is now   
   obviously no technical justification... :]   
      
   > With that example, another reason could be that compiler hosts are   
   > powerful enough to simulate target's floating point, even if it   
   > needs to use a "bigfloat" type.   
      
   Yeah, compilers do this (gcc uses "MPFR").  It's not a huge   
   inefficiency I think (after all, how much of the compiler's time is   
   spent evaluating floating-point constant expressions?!), more just a   
   bit of work to implement accurately.   
      
   -Miles   
      
   --   
   Love is a snowmobile racing across the tundra.  Suddenly it flips over,   
   pinning you underneath.  At night the ice weasels come.  --Nietzsche   
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)