🚀 go-pugleaf

>>>>> "BK" == Bob Kline <bkline@cortex.nlm.nih.gov> writes:
[...]
BK> Here's the other case:

BK> template<size_t N> bitset<N> operator&(const bitset<N>& lhs, const
BK> bitset<N>& rhs) { return bitset<N>(lhs) &= rhs; }

BK> To which the compiler responds:

BK> "./bitset", line 333: Error: The template argument N is not a
BK> type.

BK> Why is this?  The same compiler accepts the "template<size_t N>
BK> class bitset { ... }" quoted above, so I'm puzzled.  However, this
BK> isn't the only compiler which accepts the first use of a non-type
BK> template argument and rejects the second, so I'm beginning to
BK> suspect I'm just missing something obvious.  Can someone point it
BK> out to me, please?

Until not so long ago, non-type template parameters were prohibited
for function templates (e.g., see ARM 14.4). Many compilers still
impose that limitation.

	Daveed



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article itn@lhc.nlm.nih.gov, bkline@cortex.nlm.nih.gov (Bob Kline) writes:
>A couple of questions about situations in which I'm not sure why
>the compiler (Sun's CC in this case) is rejecting some template code.
>The first case involves the following code:

>template<size_t N> class bitset { ... };
>bitset<6> bs;
>
>The compiler complains:
>   Error: Template parameter N requires an expression of type unsigned. 

The ARM disallowed conversions in template arguments. The draft standard
allows various conversions. The latest Sun compiler accepts this code.
(See about upgrading your compiler to the 4.1 release.)


>Here's the other case:

>template<size_t N>
>bitset<N> operator&(const bitset<N>& lhs, const bitset<N>& rhs)
>{
>    return bitset<N>(lhs) &= rhs;
>}

>To which the compiler responds:
>
>"./bitset", line 333: Error: The template argument N is not a type.

Non-type template arguments for template functions are a recent
addition to the language. The current Sun compilers do not support
that feature. The next major release will support them.

---
Steve Clamage, stephen.clamage@eng.sun.com



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Bob Kline (bkline@cortex.nlm.nih.gov) wrote:
|> A couple of questions about situations in which I'm not sure why
|> the compiler (Sun's CC in this case) is rejecting some template code.
|> The first case involves the following code:

|> template<size_t N> class bitset { ... };
|> bitset<6> bs;

|> The compiler complains:
|>    Error: Template parameter N requires an expression of type unsigned. 

In the ARM, templates always required an exact type match, with no
conversion allowed.  I believe that the current draft has lessened this
stricture somewhat, although I don't know whether this precise case or
not is affected.

I doubt that many compilers are up to date on this, so even if the draft
says its OK, you may have to wait for a later release of your compiler.

|> Two questions about this one: is this correct-- does the draft really
|> not allow an implicit conversion of the template argument here?  And
|> if it is correct, would it not be prudent to amend the bitset<N> 
|> class in the draft standard library to take an int instead of a
|> size_t template argument?  Template syntax is ugly enough already! 
|> :->}

In my bitset, I used int, to simplify life.  BUT...

My targets are all 32 bit.  Most of the time, my bitset ends up being
instantiate over UCHAR_MAX+1 (and the resulting class ends up being
called SetOfChar:-).)  Fine so far.  But imagine a 16 bit machine using
Unicode (16 bit wchar_t characters).  An int won't cut it.  For that
matter, I'm not sure a size_t will.  You need 65536, and I think that in
many cases, 65535 is all you get.

So I agree that it should be changed from size_t.  But the new type
should be unsigned long, not int.

(For the record, well over 50% of all of my bitset's have been
SetOfChar.  And in light of the above, I'm changing my bitset to use
unsigned long immediatly.)

|> Here's the other case:

|> template<size_t N>
|> bitset<N> operator&(const bitset<N>& lhs, const bitset<N>& rhs)
|> {
|>     return bitset<N>(lhs) &= rhs;
|> }

|> To which the compiler responds:

|> "./bitset", line 333: Error: The template argument N is not a type.

|> Why is this?  The same compiler accepts the "template<size_t N>
|> class bitset { ... }" quoted above, so I'm puzzled.  However, this 
|> isn't the only compiler which accepts the first use of a non-type 
|> template argument and rejects the second, so I'm beginning to suspect
|> I'm just missing something obvious.  Can someone point it out
|> to me, please?

Again, language change.  The ARM only allowed type arguments for
template functions, since it was unclear at the time when and if it
could deduce the correct function if non-type parameters were used.  The
standards committee extended this to allow for non-type parameters in
certain cases.  I don't know the exact rules, but the above is certainly
legal *now*.

Again, wait 'til next release:-).
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]