Topic: [++] Template parameter as array dimension


Author: vandevod@cs.rpi.edu (David Vandevoorde)
Date: 1996/08/19
Raw View
Following up to myself (DV):
>>>>> "JK" == J Kanze <kanze@gabi-soft.fr> writes:
DV> [...]
JK> Although this certainly doesn't hurt, IMHO, the correct procedure
JK> would be to define "phases of template instantiation", something
JK> like the phases of compilation.  In short, make it clear that
JK> argument substitution takes place before the decision as to
JK> whether the expression is constant or not.

DV> I vaguely remember something like that being discussed in
DV> Stockholm.  Unfortunately, I have no notes about this and it might
DV> have been in a private discussion. Does someone else remember
DV> this? Was it part of a motion?

I may have dreamt the above ;-)

However, I just came across a document entitled `Template Issue
Resolutions from the Stockholm Meeting' by John Spicer from the Edison
Design Group (WG21/N0917, X3J16/96-0153 for those who collect these
things).

In item 12, this document suggests changes mostly to section 5.19
(which happens to be about constant expressions) and a little in
Chapter 14 (templates), the effect of which is that non-type template
parameters (of integral or enumeration types) are valid components
in constant expressions. I'm almost positive that a motion accepting
these changes was moved.

So the current state of the C++ language definition is that one _can_
do what was shown in the original post.

 Daveed
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1996/08/14
Raw View
fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

> To check the legality of that code, you need to look up the definition
> of "constant expression" at the end of clause 5.
> If you look this up, you will probably find that it doesn't mention
> template parameters at all,[...]

Nor should it.  Although it is not really specified in the last version
of the draft that I have access to, it is not hard to imagine that the
template code must be instantiated before it can be evaluated by the
compiler.  After instantiation, there aren't any template format
parameters, just the actual arguments.

> leading to the conclusion that Sun
> reached, namely that you're not allowed to template parameters such
> as `M' above in places where a constant expression is required.

I don't think that Sun actually reached this conclusion, given that they
accept the formal parameter as a constant integral expression in the
declaration of the function, and in the declaration of the array in the
class.  While I have a very high opinion of the Sun compiler in general,
I don't think that even the people at Sun would claim that it is
absolutly free of all errors.

> However, I think the very latest draft has added some text to the
> definition of "constant expression" to make it clear that such
> cases _are_ allowed.

Although this certainly doesn't hurt, IMHO, the correct procedure would
be to define "phases of template instantiation", something like the
phases of compilation.  In short, make it clear that argument
substitution takes place before the decision as to whether the
expression is constant or not.  Consider the following:

  template< class T >
  struct X
  {
      T const         dim = 5 ;
      int             a[ dim ] ;
  } ;

IMHO, the above code should be legal if and only if the class is
instantiated with an integral type.  If the formal parameters of the
template are replaced with the actual arguments before evaluation, then
this is be the case.

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: vandevod@cs.rpi.edu (David Vandevoorde)
Date: 1996/08/16
Raw View
>>>>> "JK" == J Kanze <kanze@gabi-soft.fr> writes:
[...]
JK> Although this certainly doesn't hurt, IMHO, the correct procedure would
JK> be to define "phases of template instantiation", something like the
JK> phases of compilation.  In short, make it clear that argument
JK> substitution takes place before the decision as to whether the
JK> expression is constant or not.

I vaguely remember something like that being discussed in Stockholm.
Unfortunately, I have no notes about this and it might have been in a
private discussion. Does someone else remember this? Was it part of a
motion?

JK>  Consider the following:

JK>   template< class T >
JK>   struct X
JK>   {
JK>       T const         dim = 5 ;
JK>       int             a[ dim ] ;
JK>   } ;

I think you meant:

 // in the struct:
 static T const dim = 5;

 // elsewhere (ODR):
 T const X::dim;

 Daveed
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Date: 1996/08/08
Raw View
In article <ocrzq46u6e6.fsf@spssunp.spspme.ml.com> Colin Rafferty
<craffert@spssunp.spspme.ml.com> writes:

|> John Aldridge <jpsa@uk.gdscorp.com> writes:

|> > I reported as a bug

|> > ...

|> >    template<int M> class Matrix {
|> >    public:
|> >       Matrix (const double rhs[M][M]);
|> >    private:
|> >       double a[M][M];
|> >    };

|> > ...

|> > fails to compile with the messages:

|> > ...

|> > and Sun responded that

|> >> This is not a bug.  First, non-type parameters are not supported for
|> >> template functions this release.  Besides that, the code as submitted
|> >> is illegal anyway since M is not a constant.

|> > Are they right?

|> Their first and second sentences are correct (if they don't support it,
|> they don't support it). Their third sentence is incorrect.

The first sentence is incorrect, as this is an error in their compiler.
The second sentence may be true, but it is a non-sequitur, since there
are no template functions in the code in question.  The last sentence is
mixed: M isn't a constant, but this doesn't make the code illegal; M is
the formal parameter of the template, and cannot possibly be constant.
The corresponding *argument* (2) is a constant.

|> The draft
|> standard says this quite plainly in [temp.arg.2]:

|> "A non-type non-reference template-argument shall be a constant-
|>  expression of non-floating type, the address of an object or a function
|>  with external linkage, or a non-overloaded pointer to member."

The template *argument* is a constant expression of type int, which is
definitly allowed.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Colin Rafferty <craffert@spssunp.spspme.ml.com>
Date: 1996/08/08
Raw View
John Aldridge <jpsa@uk.gdscorp.com> writes:

> I reported as a bug

> ...

>    template<int M> class Matrix {
>    public:
>       Matrix (const double rhs[M][M]);
>    private:
>       double a[M][M];
>    };

> ...

> fails to compile with the messages:

> ...

> and Sun responded that

>> This is not a bug.  First, non-type parameters are not supported for
>> template functions this release.  Besides that, the code as submitted
>> is illegal anyway since M is not a constant.

> Are they right?

Their first and second sentences are correct (if they don't support it,
they don't support it).  Their third sentence is incorrect.  The draft
standard says this quite plainly in [temp.arg.2]:

"A non-type non-reference template-argument shall be a constant-
 expression of non-floating type, the address of an object or a function
 with external linkage, or a non-overloaded pointer to member."

--
This posting adheres to the SELF-DISCIPLINE guidelines for better
USENET discussions. See http://www.eiffel.com/discipline.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 1996/08/08
Raw View
Colin Rafferty <craffert@spssunp.spspme.ml.com> writes:

>John Aldridge <jpsa@uk.gdscorp.com> writes:
>
>>    template<int M> class Matrix {
>>       ...
>>       double a[M][M];
>>    };
>> ...
>> and Sun responded that
>>> ... the code as submitted is illegal anyway since M is not a constant.
>
>> Are they right?
>
>Their first and second sentences are correct (if they don't support it,
>they don't support it).  Their third sentence is incorrect.  The draft
>standard says this quite plainly in [temp.arg.2]:
>
>"A non-type non-reference template-argument shall be a constant-
> expression of non-floating type, the address of an object or a function
> with external linkage, or a non-overloaded pointer to member."

It's clear that an `int' template-*argument* must be a constant
expression, but that doesn't necessarily mean that a
template-*parameter* is a constant expression.
(In different terminology, the "actual parameter" must be a constant
expression, but that doesn't necessarily mean that the "formal
parameter" can be used in constant expressions.)
For example, the section of the working paper that you quote disallows
the following

 int x;
 cin << x;
 Matrix m<x>;

but it does not allow

 template<int M> class Matrix { double a[M][M]; };

To check the legality of that code, you need to look up the definition
of "constant expression" at the end of clause 5.
If you look this up, you will probably find that it doesn't mention
template parameters at all, leading to the conclusion that Sun
reached, namely that you're not allowed to template parameters such
as `M' above in places where a constant expression is required.
However, I think the very latest draft has added some text to the
definition of "constant expression" to make it clear that such
cases _are_ allowed.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]