Re: array initialiser list, order of initialisation
On Jul 11, 5:11 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <48768727$...@mk-nntp-2.news.uk.tiscali.com>,
a...@servocomm.freeserve.co.uk says...
In the following code, the initialisation of the array
elements depends on the first in the initialiser list being
initialised before the second and so on. Can I rely on that?
#include <iostream>
int main()
{
int ar[3] = {
1,
ar[0]+1,
ar[1]+1
};
std::cout
<< ar[0] << ' '
<< ar[1] << ' '
<< ar[2] << '\n';
}
As far as I can see, no. IF this used dynamic initialization,
you'd be guaranteed that the objects in the array would be
initialized in order, and you'd be guaranteed that there was a
sequence point between each initialization and the next, so
you'd get defined results.
Could you remind me where this is specified. I was looking for
it, but I couldn't find it.
More generally, I'm pretty sure that if you write something
like:
void
f()
{
T arr[ 5 ] ;
}
it is guaranteed that the constructors of arr are called "in
order", and that if one exits with an exception, the destructors
of the already constructed objects are called in the reverse
order, but I can't find this either.
What you have, however, is an array of items (ints) with no
user- declared constructors, no private or protected
non-static members, no base classes and no virtual functions.
That means what you have is an aggregate, which is static
initialized.
What he has is a variable with automatic lifetime, which can't
have static initialization. Even at namespace scope, it would
have static initialization, because of the array accesses. All
of the three compilers I have access to agree, and use dynamic
initialization.
(Whether static initialization or dynamic is involved can easily
be tested with something like:
int f() ;
int const i = f() ;
int const arr[ 3 ] = { 0, arr[0]+1, arr[1]+1 } ;
int
f()
{
return arr[2] ;
}
The initialization of i is dynamic. If the initialization of
arr is static, it takes place before the call to f() in the
initialization of i, and i is initialized with 2. If it is
dynamic, it takes place after, and i is initialized with 0.)
The only guarantee made about order of static initialization
is that it happens before dynamic initialization.
The requirements for static initialization have been carefully
formulated so that the initialization value can be determined by
the compiler. Static initialization requires all of the
initializers to be constants, and according to the current
standard, "An integral constant-expression can involve only
literals, enumerators, const variables or static data member of
integral or enumeration types initialized with constant
expressiosn, non-type template parameters of integral or
enumeration types, and sizeof expressions." Other types of
constant expressions are even more limited. In no case can a
constant expression contain an array access (which involves an
object of array type, which of course isn't an integral type).
As such,
your code currently has undefined behavior -- it could work
for some compilers, and fail for others, or change behavior
based on the compilation flags you use, or whatever.
I'm not sure that it's undefined behavior, although it's really
not very clear. There's clearly a sequence point between the
evaluation of each initializer expression, since each is a
complete expression. However, the initialization itself isn't
part of the expression, so that's not really sufficient.
It's an interesting question, actually. Suppose a type T, with
a constructor which takes an int, and something like the
following:
int
f( int i )
{
std::cout << i << std::endl ;
return i ;
}
main()
{
T arr[ 3 ] = { f( 1 ), f( 2 ), f( 3 ) } ;
}
As I said above, I'm pretty sure that the constructors must be
called in the order arr[0], arr[1], arr[2]. And f(1), must be
called, and all of its side effects must occur, before f(2) is
called. But I don't think that there's anything which
prevents an order like f(1), f(2), f(3), ctor(arr[0]),
ctor(arr[1]), ctor(arr[2]) (which could make a difference if f
had side effects, and one of the constructors threw).
It is, however, trivial to make it work correctly: instead of
int's, create an array of proxy objects that act like ints:
class Int {
int value;
public:
Int(int v) : value(v) {}
operator int &() { return value; }
};
Int ar[3] = {
1,
ar[0] + 1,
ar[1] + 1
};
Since this has a user-declared ctor, it's not an aggregate.
Since it's not an aggregate, you get dynamic initialization
instead of static initialization. Dynamic initialization
guarantees that the initialization happens in order, with a
sequence point between each initialization and the next. IOW,
it works.
He's got dynamic initialization already, so any guarantees which
apply to dynamic initialization apply here. But I'm not sure
that the behavior is defined with dynamic initialization,
either. (And as I say, although I'm sure they exists, I can't
find the guarantees concerning the order of array elements in
dynamic initialization. And the exact wording matters in this
case.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34