Pull to refresh

Comments 22

auto x1 = { 1, 2 }; // ошибка: невозможно наличие нескольких элементов при фигурной инициализации auto


В обще-то x1 будет std::initializer_list, что бы случилась ошибка, должно быть
auto x{1, 2};

Смотрите Proof — это ссылка на стандарт.
auto x1 = { 1, 2 }; // error: cannot have multiple elements in a braced-init-list with auto
Да, я уже посмотрел, но похоже там ошибка
во-первых вот тут по другому http://en.cppreference.com/w/cpp/language/template_argument_deduction#Other_contexts, ну или по ссылке ошибка.
во-вторых — это странно, таким образом получается intitializer_list никак не создать.
Никакой ошибки нет ни там ни там.
Т.к. объект только создаётся в обоих случаях будет вызван конструктор.
Эти варианты эквиваленты и сгенерируют абсолютно одинаковый ассемблерный код.
auto x{1, 2};
auto x1 = { 1, 2 };


В 11/14 — да, это одно и тоже, но суть прделожения которое в статье описывается как раз в том, что бы сделать их разными. КМК
Если второй вариант будет давать ошибку, то и такой код должен давать ошибку
for (auto x: {1, 2, 3}) { }
11/14 тут непричём. Я же написал:
Т.к. объект только создаётся в обоих случаях будет вызван конструктор

Я же написал:
Т.к. объект только создаётся в обоих случаях будет вызван конструктор



Все верно, только нужно понять конструктор какого типа?
И так как второй вариант это не прямая инициализация, то логично было бы создавать initializer_list, как и во всех остальных случаях.
Кажется, что между стандартом и cppreference.com приоритет за стандартом.
ну ок, вот ссылка на предложение
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html
там в примерах то же самое написано.
получается intitializer_list никак не создать.


Cоздавайте на здоровье
auto x = std::initializer_list<int>{1,2,3};
Ну так да, но в таком случаи и можно без auto и = вообще обойтись. Но не об этом же речь.
А, я понял в чем проблема, у нас ссылки на разные предложения. В одном так, в другом эдок. Понятно теперь.
Я опирался на ту которая на clang.llvm.org. и cppreference похоже ту да же смотрит.
Как не странно, но сайте gcc ссылка на тот же предложение что и у clang
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html

В общем все правильно написано на cppreference, а у вас в статье ссылка на старое предложение которое изменилось.
Спасибо! Поправил статью.
Спасибо! Поправил статью.
значит, ошибка в компиляторе
#define auto do{ raise(SIGSEGV); }while(0);

Я пофиксил.

Отставить панику! Смотрим стандарт, 7.1.7.4.1:
auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
auto x2 = { 1, 2.0 }; // error: cannot deduce element type
auto x3{ 1, 2 }; // error: not a single element
auto x4 = { 3 }; // decltype(x4) is std::initializer_list<int>
auto x5{ 3 }; // decltype(x5) is int

Поменялись только пункты 3 и 5. Инициализация списка как в варианте 1 осталась.

Proof

Глупо использовать в качестве пруфа ссылку на документ 13-ого года
Да, я уже обновил статью и ссылки. Спасибо.
auto x{foo()}; // x = initializer_list<int>

Странно, у меня при компиляции с C++11 (GCC 6.3.1) это все равно int.

А вообще, что им мешало сделать так:
auto foo { 1 }; // int
auto foo { { 1 } }; std::initializer_list<int>

Заодно это решило бы проблему невозможности в некоторых случаях вызова конструктора копирования при использовании универсальной™ инициализации.
Sign up to leave a comment.

Articles

Change theme settings