In article <BWH.94Jul25051521@kato.prl.ufl.edu> bwh@kato.prl.ufl.edu (Brian Hook) writes:
>
>This may have changed, but specifically what I'm referring to is:
>
>struct SomeClass
>{
>   SomeClass( const char *array_id );
>};
>
>SomeObject *object_array = new SomeObject[10]( "I'm part of array #1!" );
>SomeObject *object_array2 = new SomeObject[10]( "I'm part of array #2!" );
>
>Last time I checked this wasn't possible, and the ARM gave a pretty flimsy
>excuse for this omission.  I haven't gotten any real solid reasons why
>constructors aren't supported when creating an array of objects -- I'm not
>saying that such a reason doesn't exist, and so far I've been extremely
>happy with the ANSI committee and Bjarne's decisions, so far be it for me
>to sit back and say "This is WRONG!  Fix it!", however I would like to hear
>a sound technical reason for this omission.

 It is a nice idea. But it needs a sound technical proof that
it will WORK rather than an explanation of why it was omitted.
The onus is on the PROPOSER of an extension to show it is useful
and causes no undue problems.

 Suppose we _allow_ an array of T to be initialised by
a single argument which could be used to initialise a single T.
As your example indicates. Its clearly sensible in _some_
circumstances:

 int a[20]=10; // array of 20 ints, all initially 10

The first question is whether this can ever be ambiguous.
Can it? Can we _always_ deduce that the initialiser of
an array is intended to initialise each element rather than
the array?

 Note that even if this is _not_ the case it may not matter.
C++ has a well understood means of handling ambiguities -- diagnosing
an error :-)

Consider a TWO dimensional array:

 int b[2][2] = { 1, 2, 3, 4};

This code is currently permitted although frowned on: it should
have been written:

 int b[2][2] = { {1,2}, {3,4} };

Now consider:

 int b[2][2] = {10, 20};

Well, does that mean:

 int b[2][2] = { {10,20}, {0,0} };

or does it now mean:

 int b[2][2] = { {10, 10}, {20, 20} };

??

SO: its clear that the ability to "stream" aggregate initialisers,
that is "flatten out" the structure by eliding the "proper" braces,
and also the ability to elide trailing zero values threatens
the coherent interpretation of an initialiser as initialising
a single element of an array or all elements.

The "proper" solution is to require all the braces and refuse to
allow default zero initialisation: mandate the initialiser
must be structurally correct. But that would break a lot of C code.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

maxtal@physics.su.OZ.AU (John Max Skaller) writes, in his usual
brilliance:
> The first question is whether this can ever be ambiguous.
> Can it? Can we _always_ deduce that the initialiser of
> an array is intended to initialise each element rather than
> the array?

Yes, if we make user-generated array constructors always use the
parentheses syntax instead of the braces.

I'm imagining something like:

struct
my_class
        {
        my_class [] ( size_t this_parm_is_required, ... );

        };

my_class
first_array[ 10 ] ( some_data );
/*

        Calls the array CTOR, passing
                (implied) pointer to the raw memory of the new array.
                (implied) a size parameter
                (explicit) some_data, presumably sufficient to initialize
                this array.
*/

The internal syntax of the array CTOR is not clear to me, but I would
assume that "this" now points to an array, of possibly many levels.

I figure for more-dimensioned arrays, add more brackets and more
required parameters:

        my_class [][]
                ( size_t this_parm_is_required, size_t so_is_this, ... );


Of course, I'm assuming the point is to initialize the bunch of 'em
arbitrarily, not neccessarily to the same value.

More ambitiously, a CTOR for an array of n dimensions taking a single
explicit parameter could imply a compiler-generated array-CTOR of n+1
dimensions taking an array of that parameter-type.

In example:

        my_param_type
        data[ 10 ];

        my_class
        array_of_more_dimensions[ 10 ][ 3 ]( data );

Which would be equivalent to:

        my_param_type
        data[ 10 ];

        enum    { count = 10, };

        /*      Do-nothing ( void ) CTOR. Assuming no side-effects. */
        my_class
        array_of_more_dimensions[ count ][ 3 ];

        for( int i = 0; i < count; i++ )
                {
                /*      Re-construct. Assuming no side-effects. */
                new( &array_of_more_dimensions[ i ] )[ 3 ]( data[i] );
                }




        Tom

--
finger me for how Tehomega is coming along (at tob@world.std.com)
Author of The Burning Tower (from TomBreton@delphi.com) (weekly in
rec.games.frp.archives)

This may have changed, but specifically what I'm referring to is:

struct SomeClass
{
   SomeClass( const char *array_id );
};

SomeObject *object_array = new SomeObject[10]( "I'm part of array #1!" );
SomeObject *object_array2 = new SomeObject[10]( "I'm part of array #2!" );

Last time I checked this wasn't possible, and the ARM gave a pretty flimsy
excuse for this omission.  I haven't gotten any real solid reasons why
constructors aren't supported when creating an array of objects -- I'm not
saying that such a reason doesn't exist, and so far I've been extremely
happy with the ANSI committee and Bjarne's decisions, so far be it for me
to sit back and say "This is WRONG!  Fix it!", however I would like to hear
a sound technical reason for this omission.

To a large extent the main reason for passing arguments to arrays has been
supplanted by templates:

// old-style that I wish I could've used (is illegal)
Matrix *m = new Matrix[10](4,4); // create 4x4 matrices

// templated way that is legal
Matrix<4,4> *m = new Matrix<4,4>[10];

However, some of the older compilers I'm using don't support templates very
well.  Not that parameters to constructors NOW would be more helpful,
however it does seem like an inconsistency in the language.

Brian

--
+---------------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics       |
| Box 90315             |---------------------------------------------|
| Gainesville, FL 32607 | bwh@prl.ufl.edu                             |
+- "Style distinguishes excellence from accomplishment" - J. Coplien -+