15 ms·
This doesn't seem to address http://en.wikipedia.org/wiki/Most_vexing_parse http://en.wikipedia.org/wiki/Most_vexing_parse at all. On the other hand, if you do
by sanxiyn 13y ago
This doesn't seem to address http://en.wikipedia.org/wiki/Most_vexing_parse http://en.wikipedia.org/wiki/Most_vexing_parse at all.
On the other hand, if you don't care about backward compatibility, I guess completely eliminating constructor syntax in favor of C++11 uniform initialization syntax is a good solution as any. (But maybe curly brace haters won't like that solution.)
- SupremumLimit 13y agoI think uniform initialization needs a lot of work before it can become the one and only mechanism for initialization. Currently it isn't anywhere near uniform enough. But aside from that, I think it would be fine to use curly braces for initialization as long as they are freed from the burden of delimiting code blocks.
- jeorgun 13y agoI'd be fully in support of that if it weren't for the fact that initializer_lists end up causing their own sets of issues. For instance, type-inference is completely borked: auto foo{tmp}; results in std::initializer_list<decltype(tmp)> Not to mention issues such as std::vector<int>{ 3, 4 } // => [3, 4] vs std::vector<int>( 3, 4 ) // => [4, 4, 4, 4] Unless some alternate syntax is proposed for initializer_lists, the old syntactic forms are kind of indispensable.
- nly 13y agoThere's a proposal to fix the 'foo' case but, as an outsider, it's unclear whether it will be fixed in time for C++14. [0] The vector case is unfortunate, but I'd personally argue the defect is in the vector class. There's no significant performance advantage, that I can see, to the (n, T) construction over a default construction followed by v.resize(n, T). [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n392...