"Greg Comeau" <comeau@panix.com> wrote in message
news:97mht9$d15$1@panix3.panix.com...
> Yup.  Just an additional thought that some compilers allow
> non-type floating points, but they are providing as extensions,
> and so should not be depended upon, unless of course you use
> them fully understanding that.

What do you mean by non-type floating points?

Andrei the nosy one


---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Alexandrescu wrote:
>
> "Greg Comeau" <comeau@panix.com> wrote in message
> news:97mht9$d15$1@panix3.panix.com...
> > Yup.  Just an additional thought that some compilers allow
> > non-type floating points, but they are providing as extensions,
> > and so should not be depended upon, unless of course you use
> > them fully understanding that.
>
> What do you mean by non-type floating points?
>
> Andrei the nosy one

At a guess: non-type template parameters which are floating point,
not integral.

The following isn't Standard C++, but is allowed by some compilers:

template<float pi> float area(float radius) { return pi*radius*radius; }

(not intended to show sane code).

There's a debate on the gcc mailing list right now about whether
to remove this extension from gcc (or, rather, to deprecate it).

-- James Dennett <jdennett@acm.org>

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrei Alexandrescu wrote:
>
> "Greg Comeau" <comeau@panix.com> wrote in message
> news:97mht9$d15$1@panix3.panix.com...
> > Yup.  Just an additional thought that some compilers allow
> > non-type floating points, but they are providing as extensions,
> > and so should not be depended upon, unless of course you use
> > them fully understanding that.
>
> What do you mean by non-type floating points?

The wording was a bit clumsy, but I believe he was referring to non-type
template parameters of floating point type.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <97p8pu$qf3sf$1@ID-14036.news.dfncis.de>,
Andrei Alexandrescu <andrewalex@hotmail.com> wrote:
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:97mht9$d15$1@panix3.panix.com...
>> Yup.  Just an additional thought that some compilers allow
>> non-type floating points, but they are providing as extensions,
>> and so should not be depended upon, unless of course you use
>> them fully understanding that.
>
>What do you mean by non-type floating points?

The thread is about non-type template parameters.
I'm referring to floating ones of those.
--
Greg Comeau                   Comeau C/C++ 4.2.45 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45.2 during March!        NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In 14.1 [temp.param] the standard states:
7. A non-type template-parameter shall  not be
declared to have floating point, class, or void type.

Now I can see several problems when classes were
allowed, and have no clue what a value of type 'void'
is supposed to be, but why aren't floating point types
allowed for non-type template-parameter?
[I couldn't find the 'why' in the standard].

TIA,
Geurt



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Geurt Vos wrote:
>
> In 14.1 [temp.param] the standard states:
> 7. A non-type template-parameter shall  not be
> declared to have floating point, class, or void type.
>
> Now I can see several problems when classes were
> allowed, and have no clue what a value of type 'void'
> is supposed to be, but why aren't floating point types
> allowed for non-type template-parameter?
> [I couldn't find the 'why' in the standard].

There are at least two good reasons:

First, it creates ambiguous cases. Consider:

    template <double X> class Foo {};
    typedef Foo<1.0> Bar;
    typedef Foo<1.00000000001> Zap;

Now, are Bar and Zap the same type or not? There are 12 digits in that
last template argument; the C++ standard requires double to preserve
only 10 decimal digits of precision, but the IEC 64-bit type commonly
used as double holds about 16.

Second, it presents problems for cross-compilers. In order to evaluate
template arguments at compile time, they would have to be able to
emulate the target system's FP arithmetic, which is not currently
required and would be a major hassle in many cases.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
        "Hungarian notation is the tactical nuclear weapon of
         source code obfuscation techniques." -- Roedy Green

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A9EBA1C.660D2726@ihug.co.nz>,
Ross Smith  <ross.s@ihug.co.nz> wrote:
>Geurt Vos wrote:
>> In 14.1 [temp.param] the standard states:
>> 7. A non-type template-parameter shall  not be
>> declared to have floating point, class, or void type.
>>
>> Now I can see several problems when classes were
>> allowed, and have no clue what a value of type 'void'
>> is supposed to be, but why aren't floating point types
>> allowed for non-type template-parameter?
>> [I couldn't find the 'why' in the standard].
>
>There are at least two good reasons:
>
>First, it creates ambiguous cases. Consider:
>
>    template <double X> class Foo {};
>    typedef Foo<1.0> Bar;
>    typedef Foo<1.00000000001> Zap;
>
>Now, are Bar and Zap the same type or not? There are 12 digits in that
>last template argument; the C++ standard requires double to preserve
>only 10 decimal digits of precision, but the IEC 64-bit type commonly
>used as double holds about 16.
>
>Second, it presents problems for cross-compilers. In order to evaluate
>template arguments at compile time, they would have to be able to
>emulate the target system's FP arithmetic, which is not currently
>required and would be a major hassle in many cases.

Yup.  Just an additional thought that some compilers allow
non-type floating points, but they are providing as extensions,
and so should not be depended upon, unless of course you use
them fully understanding that.
--
Greg Comeau                   Comeau C/C++ 4.2.45 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45.2 during March!        NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ross Smith wrote:
[...]
> First, it creates ambiguous cases. Consider:
>
>     template <double X> class Foo {};
>     typedef Foo<1.0> Bar;
>     typedef Foo<1.00000000001> Zap;
>
> Now, are Bar and Zap the same type or not?

As a programmer, my answer is:  "I don't care."

Let's take a little bit different example:

     template <double X> class Foo {};
     typedef Foo<1.0/3.0> Barx;
     typedef Foo<1.1/3.3> Zapx;

When I write the code above,
I do not care whether Barx and Zapx are the
same type or different types.

In exactly the same way, I do not care if these two
types are the same or not:

    typedef unsigned T1;
    typedef size_t   T2;

[...]
> Second, it presents problems for cross-compilers. In order to evaluate
> template arguments at compile time, they would have to be able to
> emulate the target system's FP arithmetic, which is not currently
> required and would be a major hassle in many cases.

At first glance, this looks like a problem, but actually it is not.
Naturally, a decent cross-compiler will have decent, but probably
imperfect, emulation of the target system's FP arithmetic.
Thus, this non-problem has exactly the some solution:
The programmer must not care about the close cases, so either
result is correct.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]