init_priority across different namespaces

[Sergey Kljopov]

Hi,

Is init_priority affects initialization order across different namespaces?
Means in the code (the same file)
namespace x_sp { Foo a_x __attribute__ ((init_priority (2000))); }
namespace y_sp { Foo a_y __attribute__ ((init_priority (1000))); }
which object will be initialized first?

Sergey Kljopov

designated initializers extension and sparc

[Sergey Kljopov]

Hi,

Reading the text
-
In a structure initializer, specify the name of a field to initialize 
with `.fieldname =' before the element value. For example, given the 
following structure,

 struct point { int x, y; };
the following initialization
 struct point p = { .y = yvalue, .x = xvalue };
is equivalent to
 struct point p = { xvalue, yvalue };
Another syntax which has the same meaning, obsolete since GCC 2.5, is 
`fieldname:', as shown here:

 struct point p = { y: yvalue, x: xvalue };
The `[index]' or `.fieldname' is known as a designator. You can also use 
a designator (or the obsolete colon syntax) when initializing a union, 
to specify which element of the union should be used. For example,

 union foo { int i; double d; };
 union foo f = { .d = 4 };
will convert 4 to a double to store it in the union using the second 
element. By contrast, casting 4 to type union foo would store it into 
the union as the integer i, since it is an integer. (See Cast to Union.)

-
I wrote the following test:

union foo { int i; double d; };

int main(int argc, char **argv)
{
union foo f = { .d = 4 };

ASSERT_EQ(0, f.i);
ASSERT_FEQ(4.0, f.d);

return 0;
}

ASSERT_EQ and ASSERT_FEQ are some macros which checks the falue and 
gives some error messages.


It seems that this extension should be bi-endian, however it fails on 
the sparc.

What the problem with the test?

Sergey