aggregate-initialization

Consider the following code: #include <array> struct A { int a; int b; }; static std::array<A, 4> x1 = { { 1, 2 }, { 3, 4 }, { 5, 6 }, { 7, 8 } }; static std::array<A, 4> x2 = { { { 1, 2 }, { 3, 4 }, { 5, 6 }, { 7, 8 } } }; static std::array<A, 4> x3 = { A{ 1, 2 }, A{ 3, 4 }, A{ 5, 6 }, A{ 7, 8 } }; static std::array<A, 4> x4 = { A{ 1, 2 }, { 3, 4 }, { 5, 6 }, { 7, 8 } }; Compiling with gcc: $ gcc -c --std=c++11 array.cpp array.cpp:15:1: error: too many initializers for ‘std::array<A, 4ul>’ }; ^ $ NB1: Commenting out the first initialisation statement, the code compiles without error. NB2:

Lets say we have the following code: #include <iostream> #include <string> struct A { A() {} A(const A&) { std::cout << "Copy" << std::endl; } A(A&&) { std::cout << "Move" << std::endl; } std::string s; }; struct B { A a; }; int main() { B{A()}; } Here, I believe struct A is not an aggregate, as it has both non-trivial constructors and also a std::string member which I presume is not an aggregate. This presumably means that B is also not an aggregate. Yet I can aggregate initialize B. In addition this can be done without either the copy nor move constructor being called (e.g. C++0x GCC 4.5.1

This question already has an answer here: Is it defined behavior to reference an early member from a later member expression during aggregate initialization? 4 answers struct { int a,b; } s = {5, s.a+1}; According to the standard, is it safe to read "s.a" in the above example, so that s is initialized to a=5 and b=6? If so, do most compilers obey this rule? (The above compiles in VC10.) Yes, because aggregate member initialization is sequenced. [dcl.init.aggr] /2 has: When an aggregate is initialized by an initializer list , as specified in 8.5.4, the elements of the initializer list are taken

Say I want to refer to a member of an initializer_list that I already defined. Can I do it? This code compiles and gives the expected: "13 55 " in both Visual Studio and gcc , I'd just like to know that it's legal: const int foo[2] = {13, foo[0] + 42}; So what we have here is aggregate initialization covered in section 8.5.1 of the draft C++ standard and it says: An aggregate is an array or a class [...] and: When an aggregate is initialized by an initializer list, as specified in 8.5.4, the elements of the initializer list are taken as initializers for the members of the aggregate, in

Let's say I have a type and I want to make its default constructor private. I write the following: class C { C() = default; }; int main() { C c; // error: C::C() is private within this context (g++) // error: calling a private constructor of class 'C' (clang++) // error C2248: 'C::C' cannot access private member declared in class 'C' (MSVC) auto c2 = C(); // error: as above } Great. But then, the constructor turns out to not be as private as I thought it was: class C { C() = default; }; int main() { C c{}; // OK on all compilers auto c2 = C{}; // OK on all compilers } This strikes me as very

The naive, optimistic and oh.. so wrong view of the c++11 uniform initialization syntax I thought that since C++11 user-defined type objects should be constructed with the new {...} syntax instead of the old (...) syntax (except for constructor overloaded for std::initializer_list and similar parameters (e.g. std::vector : size ctor vs 1 elem init_list ctor)). The benefits are: no narrow implicit conversions, no problem with the most vexing parse, consistency(?). I saw no problem as I thought they are the same (except the example given). But they are not. A tale of pure madness The {} calls

C++0x is going to make the following code and similar code ill-formed, because it requires a so-called narrowing conversion of a double to a int . int a[] = { 1.0 }; I'm wondering whether this kind of initialization is used much in real world code. How many code will be broken by this change? Is it much effort to fix this in your code, if your code is affected at all? For reference, see 8.5.4/6 of n3225 A narrowing conversion is an implicit conversion from a floating-point type to an integer type, or from long double to double or float, or from double to float, except where the source is a