vandevod@cs.rpi.edu (David Vandevoorde) writes:

> The ARM is not necessarily a reference anymore. The latest DWP could
> be, but not realistically: something as basic as the template
> compilation model has changed twice in the last two ANSI meetings.

So what should one use as a reference?  If the ARM is no more, and the
DWP isn't yet, then is the implementor free to do whatever he wants?

IMHO, until the draft standard is in the final steps of standardization,
and is relativly stable, the ARM is the reference for production
compilers.  (If a vendor can add the new stuff without breaking ARM
compliant code, more power to him.)

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

Michael.Ball@Eng (Mike Ball) writes:

> In article 2sp@news2.ios.com, aishdas@haven.ios.com (Micha Berger) writes:
> > In general, though, it means that one should not compare Sun statements
> > or their compilers to the ANSI standard.
>
> Oh come on!
>
> Sun has the largest representation at the C++ meetings of any company,
> usually either 3 or 4 attendees.  The chairman of the committee is
> from Sun.  We take the standard very seriously indeed.

I'm more in agreement with the original poster.  As there isn't any ANSI
standard yet, I don't see how one could compare Sun statements or their
compilers to it.  Of course, this holds equally well for any other
vendor.

Also important (but with a definitly different nuance than that of the
original poster): even when there is an ISO standard, Sun's
contributions to the standard notwithstanding, you shouldn't take Sun
statements or their compilers *FOR* the standard.  (This is not in any
way meant to minimize the importance of Sun's contributions, or of their
efforts to be standard conforming.  It is simply a statement of the
reality of what a standard is.)

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

>>>>> "JK" == J Kanze <kanze@gabi-soft.fr> writes:
JK> vandevod@cs.rpi.edu (David Vandevoorde) writes:
>> The ARM is not necessarily a reference anymore. The latest DWP could
>> be, but not realistically: something as basic as the template
>> compilation model has changed twice in the last two ANSI meetings.

JK> So what should one use as a reference?  If the ARM is no more, and the
JK> DWP isn't yet, then is the implementor free to do whatever he wants?

(Or she :-) Of course (answering the last question above) :^D --- at least
if they're in a free country.

Seriously though: I said `not necessarily'. I'm sure that in the absence
of a standard, implementors decide their own references/targets in terms
of customer-pressure and standardization trends. Several claim ARM
conformance. A few provide Cfront compatibilities (EDG, for example,
provides Cfront 2.1, Cfront 3.0 and ARM compatibility modes --- yet they
also have about the most complete coverage of post-ARM features).

Similarly, the reference from a user's perspective is whatever he or she
wants it to be. I happen to have no long term constraints on my code, so
I prefer using the latest stuff as a reference. Others may prefer your
opinion below, or even stick to a subset of that until a standard exists.

JK> IMHO, until the draft standard is in the final steps of standardization,
JK> and is relativly stable, the ARM is the reference for production
JK> compilers.  (If a vendor can add the new stuff without breaking ARM
JK> compliant code, more power to him.)

To paraphrase Tanenbaum: the great thing about references is that there
are so many to choose from.

 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                             ]

In article fsf@gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
> Michael.Ball@Eng (Mike Ball) writes:
> > from Sun.  We take the standard very seriously indeed.
>
> I'm more in agreement with the original poster.  As there isn't any ANSI
> standard yet, I don't see how one could compare Sun statements or their
> compilers to it.  Of course, this holds equally well for any other
> vendor.

None the less, we take it extremely seriously, and are very eager for one
to exist :-)

> Also important (but with a definitly different nuance than that of the
> original poster): even when there is an ISO standard, Sun's
> contributions to the standard notwithstanding, you shouldn't take Sun
> statements or their compilers *FOR* the standard.  (This is not in any
> way meant to minimize the importance of Sun's contributions, or of their
> efforts to be standard conforming.  It is simply a statement of the
> reality of what a standard is.)

Both this and your first statement are absolutely correct.

I was reacting to the tone of the post, and did not word my reply
carefully enough.

Michael Ball
SunSoft Development Products
---
[ 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
]

In article <199608192003.NAA11797@cygany.eng.sun.com>
Michael.Ball@Eng.Sun.COM (Mike Ball) writes:

|> In article fsf@gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
|> > Michael.Ball@Eng (Mike Ball) writes:
|> > > from Sun.  We take the standard very seriously indeed.
|> >
|> > I'm more in agreement with the original poster.  As there isn't any ANSI
|> > standard yet, I don't see how one could compare Sun statements or their
|> > compilers to it.  Of course, this holds equally well for any other
|> > vendor.

|> None the less, we take it extremely seriously, and are very eager for one
|> to exist :-)

I can believe that.  I believe that this is (or at least should be) true
of all of the implementors targetting stability.  In an earlier posting,
you mentioned having promised to break code "just once more"; I can
imagine that both you and your users will be happy to have this breakage
behind them.  And of course, in order to maintain this promise, you have
to wait until there is a standard (or something reasonably close) before
introducing most of the new features.

|> > Also important (but with a definitly different nuance than that of the
|> > original poster): even when there is an ISO standard, Sun's
|> > contributions to the standard notwithstanding, you shouldn't take Sun
|> > statements or their compilers *FOR* the standard.  (This is not in any
|> > way meant to minimize the importance of Sun's contributions, or of their
|> > efforts to be standard conforming.  It is simply a statement of the
|> > reality of what a standard is.)

|> Both this and your first statement are absolutely correct.

|> I was reacting to the tone of the post, and did not word my reply
|> carefully enough.

Actually, immediatly after posting, I realized that the tone of my
posting didn't correspond to what I was trying to say.  My real point
was that, despite Sun's contributions, Sun does not have any special
privileges with regards to the standard, and the Sun compiler will not
be an official reference implementation.  When arguing whether this or
that is conforming, according to the standard, what a particular
compiler does may be an interesting data point, but it doesn't prove
anything one way or another.
--
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
                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
]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>
> >John Aldridge <jpsa@uk.gdscorp.com> writes:
> >
> >|>  template<int M> class Matrix { ...  };
> ...
> >|>  template<int M> Matrix<M>::Matrix (const double rhs[M][M])  [ line A ]
> ...
> >|>  Matrix<2> m (x);                         [ line B ]
> >
> >|> and Sun responded that
> ...
> >|> > the code as submitted is illegal anyway since M is not a constant.
> >
> >|> Are they right?
> >
> >No.
> ...
> >M is a template parameter; the notion of const doesn't apply.
> >In the expansion, it is replaced with 2, which definitly is const.
>
> The draft is clear that the code at the line I've marked as "line B"
> is legal.  I don't think Sun would disagree with that; the line their
> compiler complained about was "line A".

Agreed.  Of course, it accepted exactly the same definition of the
function in the class definition as legal.

> According to the May 96
> draft, line A is indeed illegal, as Sun said.

Could you please quote the text which supports this.  It is legal
according to the ARM, and the earlier draft which I have.

> I don't know where
> you got the idea that "the notion of const doesn't apply" to template
> parameters; I certainly couldn't find any support for it in the May 96
> draft.

A template formal parameter is neither const nor non-const, as far as I
can see.  The results of an expression may have const type, but the
formal parameter should be replaced by the actual argument during
template instantiation, before the expression is evaluated.  (I'll admit
that there are a lot of vagueness concerning template instantiation, but
this seems like the only reasonable interpretation.)

> The notion of "constant-expression"-ness applies to any expression.
> The definition of constant expression in the May 96 draft is pretty clear,
> and it does not include template parameters, so "line B" is ill-formed.

This is, IMHO, because the template parameters are replaced with the
actual argument before the expression is evaluated.  The actual
argument, in this case, is 2, which is a constant expression of integral
type.

I would agree that it would be nice if the standard said this
explicitly, but it is really the only coherent interpretation.  Or are
you saying that following is illegal:

    template< int m >
    struct Array
    {
        int         a[ m ] ;
    } ;

    int
    main()
    {
        Array< 5 >      a ;
        for ( int i = 0 ; i < 5 ; i ++ )
            a.a[ i ] = i ;
        return 0 ;
    }

(Sun CC doesn't think so.)

> [...]
> >IMHO, you got the wrong person at Sun support.  Maybe the C++ specialist
> >was on vacation:-).
>
> Maybe the C++ specialist was at the recent C++ committee meeting ;-)
> Sun's response was correct (except for the bit where they referred to
> function templates rather than class templates) according to the May 96
> draft.  However, the program give _ought_ to be allowed, and I think the
> very latest draft has been changed to reflect this.

As far as I can tell, this has never been illegal, although I would
agree that it could stand some clarification (as could many things
involving template instantiation).  Still, if Sun thought it was
illegal, why do they support the above example?  And why did they accept
it in version 3.0.1?

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

kanze@gabi-soft.fr (J. Kanze) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>> >John Aldridge <jpsa@uk.gdscorp.com> writes:
>> >
>> >|>  template<int M> class Matrix { ...  };
>> ...
>> >|>  template<int M> Matrix<M>::Matrix (const double rhs[M][M])  [ line A ]
>> ...
>> According to the May 96
>> draft, line A is indeed illegal, as Sun said.
>
>Could you please quote the text which supports this.  It is legal
>according to the ARM, and the earlier draft which I have.

The text I'm referring to is 5.19 [expr.const], which gives a
definition of "constant expression" that doesn't include template
parameters.

>> The definition of constant expression in the May 96 draft is pretty clear,
>> and it does not include template parameters, so "line B" is ill-formed.
>
>This is, IMHO, because the template parameters are replaced with the
>actual argument before the expression is evaluated.  The actual
>argument, in this case, is 2, which is a constant expression of integral
>type.
>
>I would agree that it would be nice if the standard said this
>explicitly, but it is really the only coherent interpretation.

That's a reasonable interpretation, but if that were true, then 14.1
[temp.param] paragraph 5 (which says that non-type template parameters
are not lvalues, etc.) would be meaningless.  So I don't agree that it
is coherent, at least not unless you ignore 14.1/5.  And as you say it
is an interpretation which is not explicitly supported by the draft.

My interpretation, based on 14.1/5, is that template parameters
are initialized by (bound to) template arguments in a similar manner
to how function parameters are intialized by (bound to) function arguments.
(Of course, with templates the process occurs at template instantiation
time rather than at run time.)  I think this is a quite coherent
interpretation, even if it does have some unfortunate consequences,
such as the one you show below.

>Or are you saying that following is illegal:
>
>    template< int m >
>    struct Array
>    {
>        int         a[ m ] ;
>    } ;
>
>    int
>    main()
>    {
>        Array< 5 >      a ;
>        for ( int i = 0 ; i < 5 ; i ++ )
>            a.a[ i ] = i ;
>        return 0 ;
>    }

Yes, by my interpretation of the May 96 draft, that would be illegal.

The best remedy for these undesirable consequences of the "template
parameter binding" interpretation I've outlined above may be to add
text to 5.19[expr.const], rather than to instead adopt your
"template parameter macro replacement" interpretation.

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

kanze@gabi-soft.fr (J. Kanze) writes:

>A template formal parameter is neither const nor non-const, as far as I
>can see.  The results of an expression may have const type, but the
>formal parameter should be replaced by the actual argument during
>template instantiation, before the expression is evaluated.  (I'll admit
>that there are a lot of vagueness concerning template instantiation, but
>this seems like the only reasonable interpretation.)

My two-cents worth ...

I support the above interpretation. The non-type template parameter ought
to be interpreted as a non-lvalue entity. It's almost like a enum const;
it has a name but otherwise has no storage implication.

--Francis


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

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
> According to the May 96
> draft, line A is indeed illegal, as Sun said.
>

kanze@gabi-soft.fr (J. Kanze) writes:
: Could you please quote the text which supports this.  It is legal
: according to the ARM, and the earlier draft which I have.

We already established in another thread that Sun is taking the
conservative course and is /not/ trying to write a compiler against
an evolving standard.

Therefor, if Sun's compiler prohibits something the ARM considers legal
code, the compiler is broken.

In general, though, it means that one should not compare Sun statements
or their compilers to the ANSI standard.

--
Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3512 days!
micha@aishdas.org                         (16-Oct-86 -  9-Jul-96)
<a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Avodah, Chessed</a>
<a href=http://aishdas.org>AishDas Society's Home Page</a>
---
[ 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
]

>>>>> "MB" == Micha Berger <aishdas@haven.ios.com> writes:
[...]
MB> We already established in another thread that Sun is taking the
MB> conservative course and is /not/ trying to write a compiler
MB> against an evolving standard.

Hmmm... that seems like a leap of logic to me.

A Sun developer made it pretty clear that they (or their customers)
value stability over hasty changes. But he also implied they'd get a
fully conforming compiler with a single, code breaking, major version
bump.

Although I love playing with the latest features, I imagine this
is a very valuable guarantee to people who work on large, long-term
projects.

I guess this is one end of a spectrum where the other end is taken
by a vendor who boasts a 4 months product-cycle... but each released
version is crippled.

MB> Therefor, if Sun's compiler prohibits something the ARM considers
MB> legal code, the compiler is broken.

The ARM is not necessarily a reference anymore. The latest DWP could
be, but not realistically: something as basic as the template
compilation model has changed twice in the last two ANSI meetings.

MB> In general, though, it means that one should not compare Sun
MB> statements or their compilers to the ANSI standard.

I certainly do compare their compilers the DWP, and --- when it
will exist --- to the ANSI/ISO standard. They're not there yet
(no-one is), but they're not behind the pack either.

Hmm... were you in a Sun bashing mood when writing this?

 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                             ]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>John Aldridge <jpsa@uk.gdscorp.com> writes:
>
>|>  template<int M> class Matrix { ...  };
...
>|>  template<int M> Matrix<M>::Matrix (const double rhs[M][M])     [ line A ]
...
>|>  Matrix<2> m (x);          [ line B ]
>
>|> and Sun responded that
...
>|> > the code as submitted is illegal anyway since M is not a constant.
>
>|> Are they right?
>
>No.
...
>M is a template parameter; the notion of const doesn't apply.
>In the expansion, it is replaced with 2, which definitly is const.

The draft is clear that the code at the line I've marked as "line B"
is legal.  I don't think Sun would disagree with that; the line their
compiler complained about was "line A".  According to the May 96
draft, line A is indeed illegal, as Sun said.  I don't know where
you got the idea that "the notion of const doesn't apply" to template
parameters; I certainly couldn't find any support for it in the May 96 draft.
The notion of "constant-expression"-ness applies to any expression.
The definition of constant expression in the May 96 draft is pretty clear,
and it does not include template parameters, so "line B" is ill-formed.

[...]
>IMHO, you got the wrong person at Sun support.  Maybe the C++ specialist
>was on vacation:-).

Maybe the C++ specialist was at the recent C++ committee meeting ;-)
Sun's response was correct (except for the bit where they referred to
function templates rather than class templates) according to the May 96
draft.  However, the program give _ought_ to be allowed, and I think the
very latest draft has been changed to reflect this.

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

I reported as a bug that the example

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

   template<int M> Matrix<M>::Matrix (const double rhs[M][M])
   {
      memcpy (a, rhs, M*M * sizeof (double));
   }

   int main (int, char**)
   {
      static const double x[2][2] = {1, 2, 3, 4};
      Matrix<2> m (x);

      return 0;
   }

fails to compile with the messages:

"test.cxx", line 8: Error: The name M is unusable in a default
parameter.
"test.cxx", line 8: Error: An integer constant expression is required
within the array subscript operator.
"test.cxx", line 8: Error: The name M is unusable in a default
parameter.
"test.cxx", line 8: Error: An integer constant expression is required
within the array subscript operator.

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?

Cheers,
John Aldridge


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

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

>I reported as a bug that [...] fails to compile [...]
>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?

They may have been right at the time they replied, but I think
the latest draft has recently been clarified to say that
such non-type integral template parameters are considered constant.

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

In article <32088B9F.53F0@uk.gdscorp.com>, John Aldridge <jpsa@uk.gdscorp.com> wrote:
>I reported as a bug that the example
.. snipped ...
>fails to compile
.. snipped ...
>
>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?
>
>Cheers,
>John Aldridge

I would not presume to comment on the correctness or otherwise of Sun's
response, however at least one other compiler (MSVC) will accept the code with
1 minor change (I had to add a #include to get a definition for memcpy). Now I
wouldn't put Microsoft's compiler forward as a reference implementation for
the standard, but it will take your program and spew out some code that
appears to work.

Duncan Booth                                             duncan@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?


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

In article <32088B9F.53F0@uk.gdscorp.com> John Aldridge
<jpsa@uk.gdscorp.com> writes:

|> I reported as a bug that the example

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

|>    template<int M> Matrix<M>::Matrix (const double rhs[M][M])
|>    {
|>       memcpy (a, rhs, M*M * sizeof (double));
|>    }

|>    int main (int, char**)
|>    {
|>       static const double x[2][2] = {1, 2, 3, 4};
|>       Matrix<2> m (x);

|>       return 0;
|>    }

|> fails to compile with the messages:

|> "test.cxx", line 8: Error: The name M is unusable in a default
|> parameter.
|> "test.cxx", line 8: Error: An integer constant expression is required
|> within the array subscript operator.
|> "test.cxx", line 8: Error: The name M is unusable in a default
|> parameter.
|> "test.cxx", line 8: Error: An integer constant expression is required
|> within the array subscript operator.

|> 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?

No.  First, there is no "template function" in the above example, only
the template class Matrix (and its member functions).  Second, M is a
template parameter; the notion of const doesn't apply.  In the
expansion, it is replaced with 2, which definitly is const.

IMHO, you got the wrong person at Sun support.  Maybe the C++ specialist
was on vacation:-).  (For the record, my experiences with Sun Support in
France have been very positive, at least with regards to compiler
support.)

Just to check my reasoning, I compiled it with the compilers I have
handy: neither the Sun compiler nor g++ 2.7.2 would correctly
instantiate the template.  On the other hand, a five year old version of
CFront (3.0.1, from Sun) had no problem (once I added #include
<string.h> at the front).  Such is progress.  (An earlier version of g++
said "Internal compiler error", which is at least honest.)
--
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
                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
]

Duncan Booth wrote:

> I would not presume to comment on the correctness or otherwise of Sun's
> response, however at least one other compiler (MSVC) will accept the code with
> 1 minor change (I had to add a #include to get a definition for memcpy). Now I
> wouldn't put Microsoft's compiler forward as a reference implementation for
> the standard, but it will take your program and spew out some code that
> appears to work.

They're wrong, it is legal ( Template Parameters must be const, can't be
changing 'em at run time.  (Now that would be an experience!)

Borland works with this as well. ( Better referance implementation, but
still needs work )

--
#include <legalbs/standarddisclaimer>
Rich Paul                |  If you like what I say, tell my
C++, OOD, OOA, OOP,      |  employer, but if you don't,
OOPs, I forgot one ...   |  don't blame them.  ;->
---
[ 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
]