«Современный» C++: сеанс плача с причитаниями

КМК, вы все же не правы в своем отрицании :)
Если уж придираться к словам в ТЗ, то там не написано, вывести объекты, а написано перебрать объекты. Способов перебрать объекты достаточно много и все они оперяются на концепты итераторов. Ваш же итератор, если быть честным, не удовлетворяет ни одному из концептов.

C++20 и Modules, Networking, Coroutines, Ranges, Graphics. Итоги встречи в Сан-Диего

Ага, понятно, спасибо, про бросать — понятно.
А про не ловить? Вот если в вашем примере заменить dynamic_cast с указателей, на ссылки и приводить не к тому типу, да еще и try/catch-ем не обложить, что будет?
Или dynamic_cast на ссылках нужно обязательно заварачивать в try/catch блок, при чем в месте вызова?

C++20 и Modules, Networking, Coroutines, Ranges, Graphics. Итоги встречи в Сан-Диего

А как там с исключениями в constexpr-выражениях? Ну тоесть если try/catch есть — то все понятно, а если нет? Или если есть дальнейший проброс исключения? Что будет? Ну тоесть, понятно, что в итоге все должно свестись к ошибки компиляции, но вот сам вид этой ошибки не очень понятен.

ITренировка — актуальные brain teaser'ы ведущих компаний

Я не силён в химии. Что значит 3 после скобок? Должно ли это число помножатся на числа при элементах в скобках?
И в задачи с прогулами. Из примеров следует, что опоздания играют роль только если три подряд. В условии этого не сказано.

C++17 изменения вывода auto при фигурной инициализации

Как не странно, но сайте gcc ссылка на тот же предложение что и у clang
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html

В общем все правильно написано на cppreference, а у вас в статье ссылка на старое предложение которое изменилось.

C++17 изменения вывода auto при фигурной инициализации

Я же написал:

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

Все верно, только нужно понять конструктор какого типа?
И так как второй вариант это не прямая инициализация, то логично было бы создавать initializer_list, как и во всех остальных случаях.

C++17 изменения вывода auto при фигурной инициализации

А, я понял в чем проблема, у нас ссылки на разные предложения. В одном так, в другом эдок. Понятно теперь.
Я опирался на ту которая на clang.llvm.org. и cppreference похоже ту да же смотрит.

C++17 изменения вывода auto при фигурной инициализации

Ну так да, но в таком случаи и можно без auto и = вообще обойтись. Но не об этом же речь.

C++17 изменения вывода auto при фигурной инициализации

В 11/14 — да, это одно и тоже, но суть прделожения которое в статье описывается как раз в том, что бы сделать их разными. КМК
Если второй вариант будет давать ошибку, то и такой код должен давать ошибку

for (auto x: {1, 2, 3}) { }

C++17 изменения вывода auto при фигурной инициализации

ну ок, вот ссылка на предложение
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html
там в примерах то же самое написано.

C++17 изменения вывода auto при фигурной инициализации

Да, я уже посмотрел, но похоже там ошибка
во-первых вот тут по другому http://en.cppreference.com/w/cpp/language/template_argument_deduction#Other_contexts, ну или по ссылке ошибка.
во-вторых — это странно, таким образом получается intitializer_list никак не создать.

C++17 изменения вывода auto при фигурной инициализации

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

В обще-то x1 будет std::initializer_list, что бы случилась ошибка, должно быть

auto x{1, 2};