Comments 14
Жучка за внучку, внучка за бабку, бабка за дедку. С++11 прекрасен, когда он полностью поддерживается компилятором. В частичной поддержке постоянно чего-то не хватает.
Видимо, именно поэтому GCC и clang так наперегонки старались заявить о полной поддержке стандарта. Поскольку особенности языка рассчитаны на взаимодействие друг с другом, даже реализованные фичи будут оставаться неполноценными без своих оставшихся за бортом товарищей. Чего стоит убогий emplace в Visual Studio, реализованный только для move-семантики по причине отсутствия тех же variadic template. Тем не менее, когда накоплена некая критическая масса обновлений, уже можно серьёзно работать, просто приходится держать в уме, какие вещи ещё лучше не трогать. Что же до полной поддержки, то радоваться рано, несмотря на бравурные реляции. В их обещаниях, похоже, ставится знак равенства между полной реализацией стандарта и полной реализацией core features. А вот STL недоделана что там, что там. Лично столкнулся с тем, что в i/o streams в GCC до сих пор не реализована семантика перемещений. Что до clang, то буквально вчера видел жалобы на то, что его sort выдаёт неверные результаты, причём не нытьё в стиле «у меня компилятор сломался», а реально проверенный на других компиляторах, доказанный случай.
Да ладно, сделали ведь уже variadic templates
А можно по-подробнее про сломавшуюся сортировку?
Проверенный на других компиляторах — не значит коррекрный с точки зрения стандарта. Не все компараторы корректны. Но хотелось бы подробностей.
И да, компилятор к std::sort имеет довольно опосредованное отношение.
И да, компилятор к std::sort имеет довольно опосредованное отношение.
В общем случае — опосредованное, но GCC и clang всё же поставляются с разработанными той же командой библиотеками, заточенными специально под свой компилятор. По поводу сортировки я имел в виду этот случай.
Clang не поставляется со стандартной библиотекой C++. Clang может работать как с libstdc++, так и с libc++.
std::less_equal<int>() не даёт strict weak ordering, код некорректен. www.sgi.com/tech/stl/StrictWeakOrdering.html
std::less_equal<int>() не даёт strict weak ordering, код некорректен. www.sgi.com/tech/stl/StrictWeakOrdering.html
Так и не понял, как работате
first(std::get<Indices>(first_args)...)?Это так называемая распаковка. При подстановке в Indices конкретного набора индексов, допустим {0, 1, 2} это выражение раскроется в
first(std::get<0>(first_args), std::get<1>(first_args), std::get<2>(first_args))
вот не очень понятен переход от
first(std::get(first_args)...)
к
first(std::forward(std::get(first_args))...)
чем первая конструкция плоха?
first(std::get(first_args)...)
к
first(std::forward(std::get(first_args))...)
чем первая конструкция плоха?
Первая конструкция плоха тем, что может «потерять» тип передаваемых аргументов. В первую очередь это относится к rvalue references: в функции с ними идёт работа как с обычными ссылками, и как обычные ссылки они передаются дальше. А значит, мы как минимум рискуем потерять семантику перемещения и связанные с этим оптимизации. Ну и просто есть риск запутаться в типах, вызывать не те перегрузки, которые задумывались. Чтобы избежать таких неприятностей, и используется механизм perfect forwarding.
Прикольно. Заметил, кстати, что на хабре нехватает хорошей статейки по всяким std::move, std::forward с каким-нибудь схематическим описанием механизма. Да и новых «умных» указателей. Может, я пропустил статью, конечно.
Sign up to leave a comment.
Нумерация аргументов variadic template, или что скрывает скромный pair