In article <21bg2h$i4d@urmel.informatik.rwth-aachen.de> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:
>gcato@st6000.sct.edu (Vaughn Cato) writes:
>>  Has the restriction that types are the only kind of function template
>>parameters allowed been lifted from the current proposal?  If not, it seems
>>that constructions such as the following are illegal:
>>
>>template <int N> class FloatArray {/*...*};
>>
>>template <int N> void SortFA(FloatArray<N> &array);

As far as I know, not yet, but hopefully your code will soon be
allowed.  Make sure you let your compiler writers know that you want
template functions with non-type template arguments implemented now
and lobbied for in ISO C++ meetings.  After which committee meeting
can the C++ community expect many template issues like this to be
resolved?  I'm curious if the following is being considered:

 template<class T, size_t N>
 void assign( Array<T>& a, T (&a)[N] );   // just wondering if legal

>Of course, this can most elegantly been dealt with by
>template <int N> class SortFA {
> static void operator() (FloatArray<N> &array) {/*...*/}
>};
>declare an instantiation with
>template <integer> SortFA instance;
>
>This is the most straightforward use of angels (or pseudo-classes).

I'm confused.  Why is the above manual instantiation better than
Vaughn's code:

 FloatArray<10> a;
 //...
 SortFA(a);

In fact, I'm not exactly sure how you would use your "angels".

>Unfortunately, for some quiet and never nowhere explained reason,
>static operators are disallowed. [...]

A static function is within the scope of the class.  That means if
static operators were allowed, you could only use them inside other
class member functions or by explicitly scoping them:

 FloatArray<10> foo( FloatArray<10>& a, FloatArray<10>& b ) {
    return FloatArray::operator+(a,b); // if static operators allowed
 }

Jamshid Afshar
jamshid@emx.cc.utexas.edu

To anyone who might know,
  Has the restriction that types are the only kind of function template
parameters allowed been lifted from the current proposal?  If not, it seems
that constructions such as the following are illegal:

template <int N> class FloatArray {
  ...
};

template <int N> void SortFA(FloatArray<N> &array)
{
  ...
}

  Thank you,
  Vaughn Cato (gcato@st6000.sct.edu)

gcato@st6000.sct.edu (Vaughn Cato) writes:

>To anyone who might know,
>  Has the restriction that types are the only kind of function template
>parameters allowed been lifted from the current proposal?  If not, it seems
>that constructions such as the following are illegal:

>template <int N> class FloatArray {
>  ...
>};

>template <int N> void SortFA(FloatArray<N> &array)
>{
>  ...
>}
Of course, this can most elegantly been dealt with by
template <int N> class SortFA {
 static void operator() (FloatArray<N> &array) {
 ...
 }
};
declare an instantiation with
template <integer> SortFA instance;

This is the most straightforward use of angels (or pseudo-classes).
Unfortunately, for some quiet and never nowhere explained reason,
static operators are disallowed. Of course, you can leave out the
static keyword, and it will still work (though probably with
innecessary parameter passing overhead). But then you violate the
style rule that a pseudo class should only contain static members.
A pity, since this extension would mean with most compilers simply
leaving OUT a check for non-staticness, and would orthogonalize
the language. And static operators are as easy to understand as
static functions: they simply get no information about the specific
obejct they deal with (no this-pointer) except of the type
(they wouldn't have been called otherwise).

Of course this prohibits other elegant pseudo-class usages, such as
an efficient pseudo-constant i, which will efficiently work
in multiplication with other data types.

But leave out static, and you get the desired functionality with
only minor overhead (passing of a nonsensical this-pointer).

I'd strongly discourage use of constructors for this, because then
you enter into the contexts of object creation and destruction,
something with entirely different semantics, and possible surprises
in involuntary uses by casts etc.
--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen