A better technique than initializer_list. Worth a defect report?

[Elias Salomão Helou Neto]

Sorry if i kind of cross-post, but I could not wait for the feedback
in the moderated forum, I also corrected some errors and improved the
title. According to GCC we have the following:

template< unsigned dimen, class vtype = const unsigned& >
struct n_vect
{
vtype head;
n_vect< dimen - 1, vtype > rest;
};

template< class vtype >
struct n_vect< 1u, vtype >
{
vtype head;
};

void myFun( n_vect< 10 >& par )
{
}

int main()
{
// (0) OK:
n_vect< 10 > test = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

// (1) Error (at least for gcc). Why?
myFun( {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} );

//(3) compiles if -std=c++0x is used:
myFun( n_vect< 10 >{1, 2, 3, 4, 5, 6, 7, 8, 9, 10} );

return( 0 );
}

I will later explain the practical motivation for it (this will make
clear why the code is templated), but for now let us focus on the fact
that, at least from gcc's point of view, the new standard allows (3)
but not (1).

If disallowing (1) is not a bug in gcc, I think that adding it to the
language would be a major improvement. Much more than the flawed
std::initializer_list approach, why it is flawed will become clear in
the case study below. Notice that the semantics is obvious: create an
unnamed temporary struct as if (0) had been used. Furthermore it
interacts nicely with the rest of the language and will introduce no
bugs: it will be allowed only when creating a const reference in a
function call. It will not break existing code since current working
code cannot use this construct.

Notice that myFun is not a template but that could be possible either
under some fairly reasonable rules (namely, if the function is
templated by an integral type, say n, and the concrete type generated
by instatiating the template with n = ( length of the {}-list ) is
initializable with the {}-list, consider it a match). Overload
resolution would follow the same rules as usual, just look for
signatures with POD types of the proper size, if they do not exist
choke. Stop also if there is an ambiguity in any case.

++++++++++++++++++++++++++++++++++++++++++

Now for the case that motivated the example. While it may be true that
there are reasons for matrices to be kept outside of STL, it is a pity
that no truly natural, efficient and general (in n) implementation of
an n-dimensional (with n being an arbitrary compile-time constant)
exists. By efficient I mean that should behave, up to some
optimizations (such as reference shortcuting even within nested
structs) exactly as handcrafted code for that specific dimension. And
by natural, I mean that members with template-dependent number of
parameter should be as similar to someFun( arg1, ..., argn ) as
possible and, of course, type safe.

As for examples, notice that with that we could have a template

template < unsigned dim >
class nd_matrix{

public:

nd_matrix( const n_vect < dim>& size );
value_type& operator()( const n_vect< dim >& pos );
template< unsigned n >
nd_matrix< n > reshape( const n_vect< n >& new_size );
...
};

And use things like

nd_matrix< 5 > A( { 1, 2, 3, 4, 5 } );
A( { 0, 0, 2, 3, 4 } ) = 1;
nd_matrix< 1 > B( { 120 } );
B = A.reshape( { 120 } ); // Will match A.reshape< 1 >
nd_matrix< 2 > C( B.reshape( { 3, 2, 20 } ) );

We could also endow the STL containers, say std::vector, with

template< class T >
template< unsigned n >
vector< T >::vector< T >( const n_vect& data );

and achieve the nicest effect:

std::vector< double > TeXVersions( { 3, 3.1, 3.14, 3.141 } );

or, if you would like:

std::vector< double > TeXVersions = { 3, 3.1, 3.14, 3.141 } ;

one could apply automatic conversion rules for overloading resolution:
whenever there is no signature with an "exact" POD data match, try
using a conversion.

Now, std::initializer_list is a glorified simple container, that
happens to carry an extra memory for its size (take a look at
http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01223.html
for an example implementation) and does not allow for the
optimizations we require. When using n-dimensional array access within
a tight loop, it is unacceptable to have the extra burden of using a
run-time loop instead of a unrolled version to calculate the position
of the data, forcing the user to drop std::initializer_list in favor
of manually coding.

++++++++++++++++++++++++++++++++++++++++++

To summarize, the n_vect technique above would:

1) Allow loop unrolling and other efficient automatic code generation
methods;
2) Perfectly replace std::initializer_list in every of its uses by
means of the template technique exemplified by reshape;

So, why not? Should I submit a defect report? Or am I completely/
partially/a bit wrong?

Thank you for your time,
Elias.

 

[Elias Salomão Helou Neto]

Oops!

The correct signature is, of course

void myFun( const n_vect< 10 >& par )

 

[Elias Salomão Helou Neto]

Also,

nd_matrix< 3 > C( B.reshape( { 3, 2, 20 } ) );

instead of

nd_matrix< 2 > C( B.reshape( { 3, 2, 20 } ) );

Sorry,
Elias.

 

[Vladimir Jovic]

Also,

nd_matrix< 3 > C( B.reshape( { 3, 2, 20 } ) );

instead of

nd_matrix< 2 > C( B.reshape( { 3, 2, 20 } ) );

Did you copy & paste your example?
Are there more errors?

 

[Elias Salomão Helou Neto]

Did you copy & paste your example?
Are there more errors?

I am sorry about that, but I had to simplify a little bit the code I
pasted and ended up making these mistakes. The code does not contain
typing errors anymore, I believe.

 

[Elias Salomão Helou Neto]

Now, I've come to realize that the new standard does allow for such
things even more naturally with the addition of variadic templates - a
great idea. For example:

unsigned variadic_sum( unsigned val )
{
return( val );
}

template< typename... Args >
unsigned variadic_sum( unsigned first, Args... rest )
{
return( first + variadic_sum( rest... ) );
}

and now we can use:


variadic_sum( 1, 2, 3, 4, 5 );
variadic_sum( 1, 2, 3, 4 );

That's great! I loved it and I am starting to use -std=c++0x from now
on, so my new n-dimensional library will not be valid C++ until at
least the end of 2011, but I don't really care right now.

Still, the ad hoc std::initializer_list does not sound a good idea, as
the "n_vect idiom" above (which would be enabled by a simple and
natural addition to the language) is far more useful, general and, at
least to me, much more natural.

 

[Vladimir Jovic]

Now, I've come to realize that the new standard does allow for such
things even more naturally with the addition of variadic templates - a
great idea. For example:

What you posted in the original post :

{1,2,3,4,5,6,7,8,9,10}
is the initializer list for PODs, and you can only pass when you create
a POD variable :

typedef int[10] myArr;
const myArr arr = { 1,2,3,4,5,6,7,8,9,10};

but this can not be done for example like this :
class A
{
public :
myArr arr;

A() : arr( { 1,2,3,4,5,6,7,8,9,10} )
{}
};

or like you did in the original post (with corrections) to pass it to a
function, which will create a POD.

I do not know about c++0x, but I think someone told me it will be possible.

But you probably know all this