This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ PATCH: Disallow floating-point literals in integral-constant expressions


Marcin Dalecki <martin@dalecki.de> writes:

| On 2005-02-02, at 05:52, Gabriel Dos Reis wrote:
| 
| > Joe Buck <Joe.Buck@synopsys.COM> writes:
| >
| > | On Tue, Feb 01, 2005 at 12:16:14PM -0800, Mark Mitchell wrote:
| > | > My thinking is that we've been disallowing template parameters of
| > | > floating-point type for a while now.  If we really want to allow
| > | > constant expressions of floating-point type forever more, we
| > ought to
| > | > also allow template parameters of floating-point type as well.
| > |
| > | I would argue against allowing template parameters of floating-point
| > | type, because you get two distinct functions instead of one because
| > | of rounding errors: func<1.0> vs func<0.9999999999999>.
| >
| > Not that I'm a fan of that extension, but I'm not convinced by that
| > argument.  How is it different from
| >
| >     func<some-integer-value>
| 
| Expressed in terms of formal logic: The main difference is that for
| floating point values the
| model as given by a CPU is only a homology and not an ontology.
| Or bluntly speaking - there are multiple different bit patterns, which
| can represent the
| same floating point value, 

The same is true for integer values.  Think sign-magnitude.

| like for example 0.1 == 1.0e-1. Think about it and

Think normalization.  

What is important is not the bit pattern, but the *value*.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]