I have the following constructor:
class A {
template<class ...T>
A(std::initializer_list<T> && ... args);
}
And I have the code for that class:
A a1 = {{5.0f, 6.0f}, {-7.0f, 8.0f}};
A a2 = {{{5.0f, 3.f}, {6.0f, 7.f}}, {{-7.0f, 9.f}, {12.f, 8.0f}}};
a1 can be compiled and a2 can't be compiled. I understand, curly braces are only syntax sugar and not making the type by default, only when passing it to function with arguments that can be initilized with initilizer_list (e.g. std::initializer_list<float> in case of A and variable a1).
I wonder, is there any workaround that can help passing any dimensional std::initializer_list<std::initializer_list<std::initializer_list<...>...>...> to function/constructor?
I checked documentation and tried several different hacks but it will not work.
So, basic answer would be it is not possible.
It is not possible to make constructor or any other function accepting brace list of undefined number of brace lists because brace list has no type and cannot be implicitly converted to std::initilizer_list<...>.
std::initializer_list...>...> , the form
must have partial specialization , and then please reference to :
The program is ill-formed if an explicit or partial specialization of std::initializer_list is declared.
(since C++17)
https://en.cppreference.com/w/cpp/utility/initializer_list
Related
I've been going through 'A Tour of C++' and Bjarne uses the the c++11 initializer list feature in member initialization in a constructor, like so (using curly brackets):
A a;
B b;
Foo(Bar bar):
a{bar.a}, b{bar.b}
{}
This, however doesn't compile prior to c++11. What is the difference with the old member initializer list (using round brackets):
Foo(Bar bar):
a(bar.a), b(bar.b)
{}
So what is the difference and when should one be preferred over the other?
So what is the difference?
Round brackets only work for non-class types, or types with a suitable constructor for the number of arguments in the brackets.
Squiggly braces work for these, and also for aggregates - simple struct or array types with no constructor. So the following will work:
struct {
int a,b;
} aggregate;
int array[2];
Foo() : aggregate{1,2}, array{3,4} {}
Finally, braces will match a constructor taking a suitably-typed initializer_list, rather than a constructor with parameter(s) to match the arguments. For example:
std::vector<int> v1;
std::vector<int> v2;
Foo() :
v1(10,2), // 10 elements with value 2
v2{10,2} // 2 elements with value 10,2
{}
when should one be preferred over the other?
Prefer round brackets if you want to make it clearer that the initialisation is using a constructor rather than aggregate or initializer_list; or to force use of a specific constructor.
Prefer braces when you need a form of initialisation not otherwise supported; or when you just want the initialisation to "do the right thing".
In the cases where both do the same thing, the choice is largely aesthetic.
There can be a difference in a few really annoying edge cases:
std::vector<int> v{3, 2}; // constructs a vector containing [3, 2]
std::vector<int> u(3, 2); // constructs a vector containing [2, 2, 2]
That is true regardless of whether v and u are just variables in a function or are members of a class initialized in an initialization list.
But outside the cases where a std::initializer_list<T> constructor overlaps with a normal constructor taking the same number of arguments, there is no difference.
The short description is: the notation in the member initializer list matches that of variables initialized elsewhere. Sadly, the description of what it does is not as easy at all because there are two somewhat conflicting changes relating to the use of curly braces for constructor calls:
The unified initialization syntax was intended to make to make have all constructions use curly braces and it would just call the corresponding constructor, even if it is the default argument or the type doesn't have a constructor at all and direct initialization is used.
To support variable number of arguments, curly braces can be used to provide an std::initializer_list<T> without an extra pair of parenthesis/curly braces. If there is a constructor taking an std::initializer_list<T> (for a suitable type T) this constructor is used when using curly braces.
Put differently, if there is no std::initializer_list<T> constructor but some other user defined constructor the use of parenthesis and curly braces is equivalent. Otherwise it calls the std::initializer_list<T> constructor. ... and I guess, I'm missing a few details as the entire initialization is actually quite complicated.
Given:
struct X {
int m;
std::string s;
};
I can do:
X x; // invokes automatically defined default ctor
X y = { 5 }; // invokes whatever became of the original struct initialization but now maybe runs through C++ initializer-lists?
X z = { 5, "yolo" }; // I assume this is an initializer-list that is being handled by some rule for structs that either runs through a compiler created ctor or copy-from-initializer-list that is similarly compiler-created
and even...
std::vector<X> vx;
vx.push_back({ 99, "yo" }); // okay
But not...
vx.emplace_back(99, "yo"); // error VS 2017 v. 15.7.4
vx.emplace_back({99, "yo"}); // error VS 2017 v. 15.7.4
I'm not understanding the rules between initializer-lists, implicitly defined (or compiler defined) ctors, and forwarding functions like emplace_back()
Would someone be so kind as to either point me to the necessary bits of the standard or a good article on an in-depth discussion of what's become of all of the rules around structs and implicit construction and other compiler-supplied members such as copy / move operators?
I seem to be in need of a more comprehensive rules lesson - because it seems like emplace_back() ought to work for one of either emplace_back(int, std::string), or for emplace_back(initializer-list) - no?
X is an aggregate. While the specific definition of aggregate has changed in every standard, your type is an aggregate in all of them.
List-initialization for an aggregate does aggregate-initialization here. There's no constructor here - there's no "auto" constructor, no synthesized constructor. Aggregate-initialization does not create constructors or go through that mechanism. We're directly initializing each class member from the appropriate initializer in the braced-init-list. That's what both your y and your z are doing.
Now, for the second part. The relevant part of vector looks like:
template <typename T>
struct vector {
void push_back(T&&);
template <typename... Args>
void emplace_back(Args&&...);
};
A braced-init-list, like {99, "yo"}, does not have a type. And you cannot deduce a type for it. They can only be used in specific circumstances. push_back({99, "yo"}) works fine because push_back takes an X&& - it's not a function template - and we know how to do that initialization.
But emplace_back() is a function template - it needs to deduce Args... from the types of its arguments. But we don't have a type, there's nothing to deduce! There are some exceptions here (notably std::initializer_list<T> can be deduced), but here, we're stuck. You would have to write emplace_back(X{99, "yo"}) - which creates the X on the caller's side.
Similarly, emplace_back(99, "yo") doesn't work because emplace uses ()s to initialize, but you cannot ()-initialize an aggregate. It doesn't have a constructor!
I've been going through 'A Tour of C++' and Bjarne uses the the c++11 initializer list feature in member initialization in a constructor, like so (using curly brackets):
A a;
B b;
Foo(Bar bar):
a{bar.a}, b{bar.b}
{}
This, however doesn't compile prior to c++11. What is the difference with the old member initializer list (using round brackets):
Foo(Bar bar):
a(bar.a), b(bar.b)
{}
So what is the difference and when should one be preferred over the other?
So what is the difference?
Round brackets only work for non-class types, or types with a suitable constructor for the number of arguments in the brackets.
Squiggly braces work for these, and also for aggregates - simple struct or array types with no constructor. So the following will work:
struct {
int a,b;
} aggregate;
int array[2];
Foo() : aggregate{1,2}, array{3,4} {}
Finally, braces will match a constructor taking a suitably-typed initializer_list, rather than a constructor with parameter(s) to match the arguments. For example:
std::vector<int> v1;
std::vector<int> v2;
Foo() :
v1(10,2), // 10 elements with value 2
v2{10,2} // 2 elements with value 10,2
{}
when should one be preferred over the other?
Prefer round brackets if you want to make it clearer that the initialisation is using a constructor rather than aggregate or initializer_list; or to force use of a specific constructor.
Prefer braces when you need a form of initialisation not otherwise supported; or when you just want the initialisation to "do the right thing".
In the cases where both do the same thing, the choice is largely aesthetic.
There can be a difference in a few really annoying edge cases:
std::vector<int> v{3, 2}; // constructs a vector containing [3, 2]
std::vector<int> u(3, 2); // constructs a vector containing [2, 2, 2]
That is true regardless of whether v and u are just variables in a function or are members of a class initialized in an initialization list.
But outside the cases where a std::initializer_list<T> constructor overlaps with a normal constructor taking the same number of arguments, there is no difference.
The short description is: the notation in the member initializer list matches that of variables initialized elsewhere. Sadly, the description of what it does is not as easy at all because there are two somewhat conflicting changes relating to the use of curly braces for constructor calls:
The unified initialization syntax was intended to make to make have all constructions use curly braces and it would just call the corresponding constructor, even if it is the default argument or the type doesn't have a constructor at all and direct initialization is used.
To support variable number of arguments, curly braces can be used to provide an std::initializer_list<T> without an extra pair of parenthesis/curly braces. If there is a constructor taking an std::initializer_list<T> (for a suitable type T) this constructor is used when using curly braces.
Put differently, if there is no std::initializer_list<T> constructor but some other user defined constructor the use of parenthesis and curly braces is equivalent. Otherwise it calls the std::initializer_list<T> constructor. ... and I guess, I'm missing a few details as the entire initialization is actually quite complicated.
In a talk about initialization lists, I understood Stroustrup basically saying that the new construction syntax with curly braces is supposed to be a general replacement for all the previous construction syntaxes:
X x1(); // most vexing parse ... doesn't work as intended
X x2(x1);
X x3 = x1;
X x4 = X();
Instead, the new syntax is supposed to be used uniformly as a possible replacement that you can use in every situation ... again, that's the core message that I took from his talk. Maybe I misunderstood him.
So, the question is, how generic is this syntax? Is it possible to never use old-style construction in new C++11 code or are there situations where you have to revert?
This question was triggered/motivated when I encountered the following error, which I believe is an error in the compiler (but I'd be happy to be corrected).
struct X {};
int main() {
X x;
X& y{x}; // works with (x)
X& z{y}; // works with (y)
}
Which doesn't compile on g++ 4.7.1 nor does it on ideone's 4.5.1.
prog.cpp: In function 'int main()':
prog.cpp:5:9: error: invalid initialization of non-const reference of type 'X&' from an rvalue of type '<brace-enclosed initializer list>'
prog.cpp:6:9: error: invalid initialization of non-const reference of type 'X&' from an rvalue of type '<brace-enclosed initializer list>'
Note that it works when I replace X with int.
Brace initialization works everywhere an initializer is used. There are situations where you have to use parens in order to access a constructor that a brace initializer cannot access, but they are rare.
std::vector<int> v(1,1);
std::vector<int> v{1,1};
vector<int> happens to have a specialized constructor that takes two ints and is therefore ambiguous with trying to construct a vector two ints long. The ambiguous constructor exists only for backwards compatibility. New classes should not be defined with any constructors that would conflict with an initializer_list.
The ambiguity is resolved by the fact that brace initialization syntax prefers initializer_list constructors over other constructors that would otherwise match. If you want to resolve the ambiguity in favor of using the non-initializer_list constructor then you can't use brace initialization.
Bjarne Stroustrup writes
The uniform use of {} initialization only became possible in C++11, so older C++ code uses () and = initialization. Consequently, the () and = may be more familiar to you. However, I don't know any logical reason to prefer the () notation except in the rare case where you need to distinguish between initialization with a list of elements and a list of constructor arguments.
— The C++ Programming Language, Fourth Edition §17.3.2.1
Your example code is perfectly legal and should work as expected. The error you're getting is simply a bug in GCC. Clang and VC++ 2012 both accept the code.
I came across a rather strange case of overload resolution today. I reduced it to the following:
struct S
{
S(int, int = 0);
};
class C
{
public:
template <typename... Args>
C(S, Args... args);
C(const C&) = delete;
};
int main()
{
C c({1, 2});
}
I fully expected C c({1, 2}) to match the first constructor of C, with the number of variadic arguments being zero, and {1, 2} being treated as an initializer list construction of an S object.
However, I get a compiler error that indicates that instead, it matches the deleted copy constructor of C!
test.cpp: In function 'int main()':
test.cpp:17:15: error: use of deleted function 'C(const C &)'
test.cpp:12:5: error: declared here
I can sort of see how that might work - {1, 2} can be construed as a valid initializer for C, with the 1 being an initializer for the S (which is implicitly constructible from an int because the second argument of its constructor has a default value), and the 2 being a variadic argument... but I don't see why that would be a better match, especially seeing as the copy constructor in question is deleted.
Could someone please explain the overload resolution rules that are in play here, and say whether there is a workaround that does not involve mentioning the name of S in the constructor call?
EDIT: Since someone mentioned the snippet compiles with a different compiler, I should clarify that I got the above error with GCC 4.6.1.
EDIT 2: I simplified the snippet even further to get an even more disturbing failure:
struct S
{
S(int, int = 0);
};
struct C
{
C(S);
};
int main()
{
C c({1});
}
Errors:
test.cpp: In function 'int main()':
test.cpp:13:12: error: call of overloaded 'C(<brace-enclosed initializer list>)' is ambiguous
test.cpp:13:12: note: candidates are:
test.cpp:8:5: note: C::C(S)
test.cpp:6:8: note: constexpr C::C(const C&)
test.cpp:6:8: note: constexpr C::C(C&&)
And this time, GCC 4.5.1 gives the same error, too (minus the constexprs and the move constructor which it does not generate implicitly).
I find it very hard to believe that this is what the language designers intended...
For C c({1, 2}); you have two constructors that can be used. So overload resolution takes place and looks what function to take
C(S, Args...)
C(const C&)
Args will have been deduced to zero as you figured out. So the compiler compares constructing S against constructing a C temporary out of {1, 2}. Constructing S from {1, 2} is straight forward and takes your declared constructor of S. Constructing C from {1, 2} also is straight forward and takes your constructor template (the copy constructor is not viable because it has only one parameter, but two arguments - 1 and 2 - are passed). These two conversion sequences are not comparable. So the two constructors would be ambiguous, if it weren't for the fact that the first is a template. So GCC will prefer the non-template, selecting the deleted copy constructor and will give you a diagnostic.
Now for your C c({1}); testcase, three constructors can be used
C(S)
C(C const&)
C(C &&)
For the two last, the compiler will prefer the third because it binds an rvalue to an rvalue. But if you consider C(S) against C(C&&) you won't find a winner between the two parameter types because for C(S) you can construct an S from a {1} and for C(C&&) you can initialize a C temporary from a {1} by taking the C(S) constructor (the Standard explicitly forbids user defined conversions for a parameter of a move or copy constructor to be usable for an initialization of a class C object from {...}, since this could result in unwanted ambiguities; this is why the conversion of 1 to C&& is not considered here but only the conversion from 1 to S). But this time, as opposed to your first testcase, neither constructor is a template so you end up with an ambiguity.
This is entirely how things are intended to work. Initialization in C++ is weird so getting everything "intuitive" to everyone is going to be impossible sadly. Even a simple example as above quickly gets complicated. When I wrote this answer and after an hour I looked at it again by accident I noticed I overlooked something and had to fix the answer.
You might be correct in your interpretation of why it can create a C from that initializer list. ideone happily compiles your example code, and both compilers can't be correct. Assuming creating the copy is valid, however...
So from the compiler's point of view, it has two choices: Create a new S{1,2} and use the templated constructor, or create a new C{1,2} and use the copy constructor. As a rule, non-template functions are preferred over template ones, so the copy constructor is chosen. Then it looks at whether or not the function can be called... it can't, so it spits out an error.
SFINAE requires a different type of error... they occur during the first step, when checking to see which functions are possible matches. If simply creating the function results in an error, that error is ignored, and the function not considered as a possible overload. After the possible overloads are enumerated, this error suppression is turned off and you're stuck with what you get.