Frederick Gotham wrote:

    [...]
> I will always favour shorter keywords over longer keywords;
> hence I'll never write "typename T" instead of "class T".

Would you prefer that the keyword be 'c' instead of 'class'?
It's a lot shorter.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 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                      ]

Gabriel Dos Reis wrote:
> On Tue, 18 Jul 2006, Dave Harris wrote:

> | Actually, as I understand it the problem is one of type checking. Given:

> |     template <double v> struct X {};

> |     void func( X<0.3333> ) {}
> |     void func( X<1.0/3.0> ) {}

> | is this two definitions of the same function that violates the
> | one-definition rule, or are there two functions that take arguments of
> | different types? The answer depends on the precision of the floating
> | point, so we can't say whether the program is type-correct without knowing
> | more about the implementation than we should.

> Isn't the same reasoning true for integer types too?

Sort of.  The value of an expression like "-1 & 1" certainly
depends on the integral representation.  On the other hand, it
doesn't (or shouldn't) depend on whether the compiler was able
to hold all intermediate values in registers, or had to spill
some to memory.  Whereas:
    double one = 1.0 ;
    double three = 3.0 ;
    double d = one / three ;
    assert( d == one / three ) ;
fails on some compilers I use (some of the time, sometimes
dependant on optimization).

I think the problem is solvable, perhaps with the introduction
of some restrictions.

I'm also not convinced that it is a real problem.  After all, we
alread ylive with the fact that it is unspecified whether:
    void func( unsigned ) ;
    void func( size_t ) ;
declares two functions or one; I don't see where such
ambiguities due to the instantiation of a template on a floating
point value makes the problem significantly worse.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 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                      ]

On Wed, 19 Jul 2006, kanze wrote:

| I'm also not convinced that it is a real problem.  After all, we
| alread ylive with the fact that it is unspecified whether:
|     void func( unsigned ) ;
|     void func( size_t ) ;
| declares two functions or one; I don't see where such
| ambiguities due to the instantiation of a template on a floating
| point value makes the problem significantly worse.

I'm trying to refrain from using the syllogism that some problems are
already existent with "unspecified beahviour", therefore we should be
able to live with another one.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

James Dennett posted:

> Most would agree that the many uses of "static" in C and C++
> are an example of *poor* use of a keyword; such terminology
> and overloading leads to much confusion.  Are you perchance
> arguing for my side of this debate?


No.

You know how a parrot can't speak English, yet it will actually speak
intelligible English. It hasn't got a clue what it's saying; it doesn't put
any thought into its words -- all it does is produce sounds.

Well that's how I treat keywords; I don't put any thought into them, I just
treat them as a sequence of characters.

I will always favour shorter keywords over longer keywords; hence I'll never
write "typename T" instead of "class T".


--

Frederick Gotham

---
[ 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                      ]

On Tue, 18 Jul 2006, Dave Harris wrote:

| Actually, as I understand it the problem is one of type checking. Given:
|
|     template <double v> struct X {};
|
|     void func( X<0.3333> ) {}
|     void func( X<1.0/3.0> ) {}
|
| is this two definitions of the same function that violates the
| one-definition rule, or are there two functions that take arguments of
| different types? The answer depends on the precision of the floating
| point, so we can't say whether the program is type-correct without knowing
| more about the implementation than we should.

Isn't the same reasoning true for integer types too?

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

Dave Harris wrote:
> richard@ex-parrot.com (Richard Smith) wrote (abridged):
> > werasm wrote:
> > > 1) Are floating point numbers non-type template parameters in the
> > > latest standard.
> >
> > Not at present.  The rationale being that when cross compiling, the
> > compiler would need to exactly emulate the floating point behaviour of
> > the target processor, right down to the details of rounding, handling
> > of NaNs and infinites, etc.
>
> Actually, as I understand it the problem is one of type checking.

Definitely.  The compiler has to understand the issues of rounding,
etc., at compile time *because* this detail can be folded into the type
system and therefore needs to be manipulated at compile time.  If it
didn't, it could simply use the lexical representation of the
expressions used (e.g. "1.0/3.0") in the type system, and defer
evaluation until run-time.

>Given:
>
>     template <double v> struct X {};
>
>     void func( X<0.3333> ) {}
>     void func( X<1.0/3.0> ) {}
>
> is this two definitions of the same function that violates the
> one-definition rule, or are there two functions that take arguments of
> different types? The answer depends on the precision of the floating
> point, so we can't say whether the program is type-correct without knowing
> more about the implementation than we should.
>
> This is not really about cross-compiling. It is about *all* compilers
> being consistent, rather than one compiler emulating one other processor.

Well, it's harder for a cross-compilers.  If a non-cross-compiler needs
to know whether 1.0/3.0 == 0.3333 at compile time, it can simply
evaluate the expression and find out.

(I appreciate that this is an oversimplification on processors that
allow their floating point characteristics to be modified at run-time,
as I believe certain IBM mainframes do.  And even on the ix86
architecture, such things can depend on whether the whether
intermediate expressions stay on the 80-bit FPU register stack or are
moved into memory.  But presumably relying on such details would be
undefined, or maybe implementation defined, behaviour.)

--
Richard Smith

---
[ 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                      ]

Frederick Gotham wrote:

>
> I will always favour shorter keywords over longer keywords; hence I'll never
> write "typename T" instead of "class T".

I favour:

As short as required to be communicative, but no shorter. My naming of
identifiers are consistent with this. If your naming of identifiers
were consistent with your parrot rationale wrt. keywords, then I would
not want to maintain your code.

I like Andrei Alexandrescu's approach in MCPP (communicative):

Template parameters are declared with class if they can only be
user-defined type, and with typename if they can also be a primitive
type.

When I'm not sure, typename suffices as it (the word) encapulates both
user and primitive types.

Kind regards,

Werner

---
[ 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                      ]

Frederick Gotham wrote:
> James Dennett posted:
>
> > Most would agree that the many uses of "static" in C and C++
> > are an example of *poor* use of a keyword; such terminology
> > and overloading leads to much confusion.  Are you perchance
> > arguing for my side of this debate?
>
>
> No.
>
> You know how a parrot can't speak English, yet it will actually speak
> intelligible English. It hasn't got a clue what it's saying; it doesn't put
> any thought into its words -- all it does is produce sounds.
>
> Well that's how I treat keywords; I don't put any thought into them, I just
> treat them as a sequence of characters.
>
> I will always favour shorter keywords over longer keywords; hence I'll never
> write "typename T" instead of "class T".

well, clearly, this It is YOUR (extremist, imho) point of view

as someone said before: "readability is more important than
writability"
I hope I never have to use a language designed by you

Diego Martins

---
[ 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                      ]

Gabriel Dos Reis wrote:
> On Wed, 12 Jul 2006, Richard Smith wrote:
>
> | Regarding the syntax, there isn't anything obvious that fits with C++
> | idea of templates.  The name of the type needs to be in scope when the
> | non-type template parameter is declared, so
> |
> |   template <typename T, T Min, T Max>
> |   struct foo {};
>
> How about
>
>     template<auto Min, auto Max>
>       struct foo { };
>
> ?
>
> It does not say exactly that Min and Max have the same type, but that
> is a minor point.

Yeah, I did think about that, but as you say, it doesn't mean exactly
the same thing.  However, it occurs to me that C++0x (probably) might
allow me to express this:

  template <auto Min, auto Max>
    where std::SameType< typeof(Min), typeof(Max) >
  struct foo {};

>  One would gain in clarity by removing the noise
> "typename T".

. until you introduce that messy where clause.

--
Richard Smith

---
[ 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                      ]

Gabriel Dos Reis posted:

> How about
>
>     template<auto Min, auto Max>
>       struct foo { };
>
> ?
>
> It does not say exactly that Min and Max have the same type, but that
> is a minor point.  One would gain in clarity by removing the noise
> "typename T".


It baffles me why anyone would write:

    typename T

when they can write:

    class T



--

Frederick Gotham

---
[ 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                      ]

werasm wrote:
> >
> >   typedef foo< /* what goes here? */, 0, 360 > angle;
>
> typedef foo
> </* nothing needed - T determined from literals - why not? :-)*/
>  0,359> angle

Well, you need *something* there, otherwise how does the compiler know
in a more complicated example, which template parameters to deduce?
For example, given:

  template <typename T, typename U, T X, U Y>
  struct foo {};

What does

  foo<long, 0, 42>

mean?  Is T specified as long and U deduced as int or vice versa?  A
place holder like "default" would perhaps suffice:

  foo< default, long, 0, 42 > // T == int (deduced); U == long
(specified)

--
Richard Smith

---
[ 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                      ]

kanze wrote:
> Gabriel Dos Reis wrote:
> > How about
>
> >     template<auto Min, auto Max>
> >       struct foo { };
> But how do you name the type within the template?

I'm wondering about why auto would be necessary when the type could be
derived from the literal (my original example: template <T min, T
max>). I've given the explanation as to why I think it not necessary,
and no one has commented as yet.

I suppose if one wants to refer to the type, in the event of it (an
auto keyword) being necessary, one could use:

template <auto<T> min, auto<T> max> or ...
template <auto<T> min, auto<T2> max> etc.

>From the template users perspective this would get rid of the
unecessary specification of T during instantiation/declaration:

ranged_type<0, 10> inst; //as opposed to ranged_type<int,0,10> inst;

I of course find the fact that floating points can't be used as
non-type template paramers very irritating too. Will this ever change
(or is it busy changing)?

Kind regards,

Werner

---
[ 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                      ]

Frederick Gotham wrote:
> Gabriel Dos Reis posted:
>
>> How about
>>
>>     template<auto Min, auto Max>
>>       struct foo { };
>>
>> ?
>>
>> It does not say exactly that Min and Max have the same type, but that
>> is a minor point.  One would gain in clarity by removing the noise
>> "typename T".
>
>
> It baffles me why anyone would write:
>
>     typename T
>
> when they can write:
>
>     class T

Because "class" is suggestive of a class type, which is
not required, possibly.  Clarity is often enhanced by
using the longer, more expressive form.

-- James

---
[ 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                      ]

James Dennett posted:


> Because "class" is suggestive of a class type, which is
> not required, possibly.  Clarity is often enhanced by
> using the longer, more expressive form.


I tend not to put thought into the meaning of keywords.

static
adj.

Having no motion; being at rest; quiescent.
Fixed; stationary.
Physics: Of or relating to bodies at rest or forces that balance each other.
Electricity: Of, relating to, or producing stationary charges; electrostatic.
Of, relating to, or produced by random radio noise.

n.
Random noise, such as crackling in a receiver or specks on a television
screen, produced by atmospheric disturbance of the signal.
Informal:
Back talk.
Interference; obstruction.
Angry or heated criticism.

--

Frederick Gotham

---
[ 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                      ]

On Mon, 17 Jul 2006, kanze wrote:

| Gabriel Dos Reis wrote:
| > On Wed, 12 Jul 2006, Richard Smith wrote:
|
| > | Regarding the syntax, there isn't anything obvious that fits with C++
| > | idea of templates.  The name of the type needs to be in scope when the
| > | non-type template parameter is declared, so
|
| > |   template <typename T, T Min, T Max>
| > |   struct foo {};
| >
| > How about
|
| >     template<auto Min, auto Max>
| >       struct foo { };
|
| > ?
|
| > It does not say exactly that Min and Max have the same type, but that
| > is a minor point.  One would gain in clarity by removing the noise
| > "typename T".
|
| But how do you name the type within the template?

decltype or auto -- if the type is ever needed.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

On Mon, 17 Jul 2006, werasm wrote:

|
| Gabriel Dos Reis wrote:
|
| > How about
| >
| >     template<auto Min, auto Max>
| >       struct foo { };
| >
| > ?
| >
| > It does not say exactly that Min and Max have the same type, but that
| > is a minor point.  One would gain in clarity by removing the noise
| > "typename T".
|
| That is exactly the kind of thing that I had in mind. Are there
| proposals in for this kind of thing at this stage (in the new
| standard)?

It was mentioned at several points late 2003 on the C++ evolution
reflector when we were exploring the design space for concepts.
However, I never made a concrete proposal, nor did anyone.

| Are there any difficulties in implementing this kind of
| thing? I could not think of reasons why not.

Apart from name mangling, I don't anticipate any.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

On Mon, 17 Jul 2006, werasm wrote:

|
| kanze wrote:
| > Gabriel Dos Reis wrote:
| > > How about
| >
| > >     template<auto Min, auto Max>
| > >       struct foo { };
| > But how do you name the type within the template?
|
| I'm wondering about why auto would be necessary when the type could be
| derived from the literal (my original example: template <T min, T
| max>).

An issue is that every use of a name (here your "T") must be
preceded by a declaration that introduces it in scope.  C++ isn't ML.

| I've given the explanation as to why I think it not necessary,
| and no one has commented as yet.

I don't believe your explanation correctly handles the language
reuqirements.

| I suppose if one wants to refer to the type, in the event of it (an
| auto keyword) being necessary, one could use:
|
| template <auto<T> min, auto<T> max> or ...
| template <auto<T> min, auto<T2> max> etc.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

On Mon, 17 Jul 2006, Richard Smith wrote:

|
| Gabriel Dos Reis wrote:
| > On Wed, 12 Jul 2006, Richard Smith wrote:
| >
| > | Regarding the syntax, there isn't anything obvious that fits with C++
| > | idea of templates.  The name of the type needs to be in scope when the
| > | non-type template parameter is declared, so
| > |
| > |   template <typename T, T Min, T Max>
| > |   struct foo {};
| >
| > How about
| >
| >     template<auto Min, auto Max>
| >       struct foo { };
| >
| > ?
| >
| > It does not say exactly that Min and Max have the same type, but that
| > is a minor point.
|
| Yeah, I did think about that, but as you say, it doesn't mean exactly
| the same thing.  However, it occurs to me that C++0x (probably) might
| allow me to express this:
|
|   template <auto Min, auto Max>
|     where std::SameType< typeof(Min), typeof(Max) >
|   struct foo {};

that is one possible solution.

| >  One would gain in clarity by removing the noise
| > "typename T".
|
| . until you introduce that messy where clause.

the messyness of the where-clause is in the eye of the beholder.

In my own uses, I rarely need to express such situation, partly
because I usually have one constant, or the "same type"-ness isn't that
important in the interface.  But, by no means I want to imply that the
speculative "auto" declaration will make redundant all other possible
ways of writing the declaration.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

Frederick Gotham wrote:
> James Dennett posted:
>
>
>> Because "class" is suggestive of a class type, which is
>> not required, possibly.  Clarity is often enhanced by
>> using the longer, more expressive form.
>
>
> I tend not to put thought into the meaning of keywords.
>
> static
> adj.

[snip]

Most would agree that the many uses of "static" in C and C++
are an example of *poor* use of a keyword; such terminology
and overloading leads to much confusion.  Are you perchance
arguing for my side of this debate?

-- James

---
[ 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                      ]

richard@ex-parrot.com (Richard Smith) wrote (abridged):
> werasm wrote:
> > 1) Are floating point numbers non-type template parameters in the
> > latest standard.
>
> Not at present.  The rationale being that when cross compiling, the
> compiler would need to exactly emulate the floating point behaviour of
> the target processor, right down to the details of rounding, handling
> of NaNs and infinites, etc.

Actually, as I understand it the problem is one of type checking. Given:

    template <double v> struct X {};

    void func( X<0.3333> ) {}
    void func( X<1.0/3.0> ) {}

is this two definitions of the same function that violates the
one-definition rule, or are there two functions that take arguments of
different types? The answer depends on the precision of the floating
point, so we can't say whether the program is type-correct without knowing
more about the implementation than we should.

This is not really about cross-compiling. It is about *all* compilers
being consistent, rather than one compiler emulating one other processor.

-- Dave Harris, Nottingham, UK.

---
[ 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                      ]

Dave Harris wrote:
> richard@ex-parrot.com (Richard Smith) wrote (abridged):
> > werasm wrote:
> > > 1) Are floating point numbers non-type template parameters in the
> > > latest standard.

> > Not at present.  The rationale being that when cross
> > compiling, the compiler would need to exactly emulate the
> > floating point behaviour of the target processor, right down
> > to the details of rounding, handling of NaNs and infinites,
> > etc.

> Actually, as I understand it the problem is one of type
> checking.

It's definitely one of type checking.

> Given:

>     template <double v> struct X {};

>     void func( X<0.3333> ) {}
>     void func( X<1.0/3.0> ) {}

> is this two definitions of the same function that violates the
> one-definition rule, or are there two functions that take
> arguments of different types?

How is this different from:

    template< int v > struct X {} ;

    void func( X< 0 > ) {}
    void func( X< -1 & 1 > ) {}   //  Consider a 1's complement machine

or for that matter, even:

    template< typename T > struct X{} ;
    void func( x< unsigned int > ) {}
    void func( X< size_t > ) {}

> The answer depends on the precision of the floating
> point,

And with signed integers, and with type arguments in the
presence of typedef's.

> so we can't say whether the program is type-correct without
> knowing more about the implementation than we should.

> This is not really about cross-compiling. It is about *all*
> compilers being consistent, rather than one compiler emulating
> one other processor.

I don't think it's that black and white.  The issue of cross
compilation means that a compiler must fully emulate the
floating point hardware of the target platform if it is to be
consistent for that platform.  This is already true for int, of
course, but emulating 1's complement (if necessary) is a lot
easier than emulating floating point (and is already necessary
anyway---something like "#if (-1 & 1) == 0" is probably in
actual use somewhere to determine whether the target is 1's
complement or not).  Where as with floating point, on the other
hand...

It may not be just cross compilation.  On some machines 1.0/3.0
is equal to 0.33333333333333333 if the value is assigned to
memory, but not if the compiler manages to keep all of the
intermediate results in a register.

Globally, it's a thorny issue, and I think that there are a
variety of motivations behind not supporting it: some due to
cross compilation, others not.  (One possibility: allow it, but
don't allow anything but floating point literals as arguments,
and define equality as absolute equality over the real numbers.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 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                      ]

Richard Smith wrote:

> Regarding the syntax, there isn't anything obvious that fits with C++
> idea of templates.  The name of the type needs to be in scope when the
> non-type template parameter is declared, so
>
>   template <typename T, T Min, T Max>
>   struct foo {};
>
> but then, even supposing the compiler could deduce template arguments
> for structs, how would T be deduced from Min and Max?  You can't
> specify Min or Max without already having specified T:

That is my question:

Given a template with parameter list (Knowing this is not valid, but
supposing it is):

template <T Min, T Max>...

IMhO he compiler should be able to immediatly see that the two
parameters in question are non-type arguments (no doubt - crystal
clear?). For this reason T should not have to be specified, but the
compiler should be able to immediatly attempt to derive T from the
literal during instantiation. Min and Max are then dependent names, and
expressions where they are involved in can be evaluated during 2nd
phase of lookup.

Is there something I'm missing?

Kind regards,

Werner


>
>   typedef foo< /* what goes here? */, 0, 360 > angle;

typedef foo
</* nothing needed - T determined from literals - why not? :-)*/
 0,359> angle
>
> --
> Richard Smith

Thanks for your response,

Werner

---
[ 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                      ]

On Wed, 12 Jul 2006, Richard Smith wrote:

| Regarding the syntax, there isn't anything obvious that fits with C++
| idea of templates.  The name of the type needs to be in scope when the
| non-type template parameter is declared, so
|
|   template <typename T, T Min, T Max>
|   struct foo {};

How about

    template<auto Min, auto Max>
      struct foo { };

?

It does not say exactly that Min and Max have the same type, but that
is a minor point.  One would gain in clarity by removing the noise
"typename T".

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

Gabriel Dos Reis wrote:

> How about
>
>     template<auto Min, auto Max>
>       struct foo { };
>
> ?
>
> It does not say exactly that Min and Max have the same type, but that
> is a minor point.  One would gain in clarity by removing the noise
> "typename T".

That is exactly the kind of thing that I had in mind. Are there
proposals in for this kind of thing at this stage (in the new
standard)? Are there any difficulties in implementing this kind of
thing? I could not think of reasons why not.

Kind regards,

Werner

>
> --
>                                                         Gabriel Dos Reis
>                                                          gdr@cs.tamu.edu
>  Texas A&M University -- Department of Computer Science
>  301, Bright Building -- College Station, TX 77843-3112

---
[ 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                      ]

Gabriel Dos Reis wrote:
> On Wed, 12 Jul 2006, Richard Smith wrote:

> | Regarding the syntax, there isn't anything obvious that fits with C++
> | idea of templates.  The name of the type needs to be in scope when the
> | non-type template parameter is declared, so

> |   template <typename T, T Min, T Max>
> |   struct foo {};
>
> How about

>     template<auto Min, auto Max>
>       struct foo { };

> ?

> It does not say exactly that Min and Max have the same type, but that
> is a minor point.  One would gain in clarity by removing the noise
> "typename T".

But how do you name the type within the template?

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 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                      ]

Hi all,

I've had the thought of writing a class for simple range checking. The
idea would be to make ranges explicit in the argument (part of the
argument type, so to speak) of a function call and to catch range
errors before the actual function is called (early).

I admit making ranges explicit in the interface (or type) is not always
advisable, but it has its advantages for domain specific cases, such as
compass angle.

Here then, is what I came up with (I know it doesn't compile):

template <T min, T max>
class in_range
{
public:
  in_range(): v_( min ){ }
  in_range( T value ): v_( check(value) ){ }
  operator T() const{ return v_; }

private:
  T& check( T& v )
  {
    if( v < min || v > max )
    {
      throw std::out_of_range( "some formatted msg..." );
    }
    return v;
  }
  T v_;
};

It would typically be used as:

void convertCompassToShip( in_range<0,360> value );

My questions are:

1) Are floating point numbers non-type template parameters in the
latest standard.
2) Why is it necessary to specify the type when the type can be derived
from the literal for nontype template arguments e.g.

in_range needs to be specified as in_range<int,0,360>, while it can
clearly be seen (or maybe not?) that the literal already has type
<int>.

Therefore - does the new standard allow for:

template <T v1, T v2> as opposed to template <T, T v1, T v2>.

Thank you,

Werner

---
[ 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                      ]

werasm wrote:
>
> 1) Are floating point numbers non-type template parameters in the
> latest standard.

Not at present.  The rationale being that when cross compiling, the
compiler would need to exactly emulate the floating point behaviour of
the target processor, right down to the details of rounding, handling
of NaNs and infinites, etc.

> 2) Why is it necessary to specify the type when the type can be derived
> from the literal for nontype template arguments e.g.

I don't think there's a fundamental technical reason why not; the two
issues that spring to mind are: what would the syntax be, and did it
seem likely in the mid-1990s when the current standard was being
produced that it would be of sufficient use to merit inclusion.  As to
the latter, my guess is: no.

Regarding the syntax, there isn't anything obvious that fits with C++
idea of templates.  The name of the type needs to be in scope when the
non-type template parameter is declared, so

  template <typename T, T Min, T Max>
  struct foo {};

but then, even supposing the compiler could deduce template arguments
for structs, how would T be deduced from Min and Max?  You can't
specify Min or Max without already having specified T:

  typedef foo< /* what goes here? */, 0, 360 > angle;

--
Richard Smith

---
[ 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                      ]