Нумерация аргументов variadic template, или что скрывает скромный pair

[hoxnox]

Жучка за внучку, внучка за бабку, бабка за дедку. С++11 прекрасен, когда он полностью поддерживается компилятором. В частичной поддержке постоянно чего-то не хватает.

[OldFisher]

Видимо, именно поэтому GCC и clang так наперегонки старались заявить о полной поддержке стандарта. Поскольку особенности языка рассчитаны на взаимодействие друг с другом, даже реализованные фичи будут оставаться неполноценными без своих оставшихся за бортом товарищей. Чего стоит убогий emplace в Visual Studio, реализованный только для move-семантики по причине отсутствия тех же variadic template. Тем не менее, когда накоплена некая критическая масса обновлений, уже можно серьёзно работать, просто приходится держать в уме, какие вещи ещё лучше не трогать. Что же до полной поддержки, то радоваться рано, несмотря на бравурные реляции. В их обещаниях, похоже, ставится знак равенства между полной реализацией стандарта и полной реализацией core features. А вот STL недоделана что там, что там. Лично столкнулся с тем, что в i/o streams в GCC до сих пор не реализована семантика перемещений. Что до clang, то буквально вчера видел жалобы на то, что его sort выдаёт неверные результаты, причём не нытьё в стиле «у меня компилятор сломался», а реально проверенный на других компиляторах, доказанный случай.

[tangro]

Да ладно, сделали ведь уже variadic templates

[drBasic]

А можно по-подробнее про сломавшуюся сортировку?

[gribozavr]

Проверенный на других компиляторах — не значит коррекрный с точки зрения стандарта. Не все компараторы корректны. Но хотелось бы подробностей.

И да, компилятор к std::sort имеет довольно опосредованное отношение.

[OldFisher]

В общем случае — опосредованное, но GCC и clang всё же поставляются с разработанными той же командой библиотеками, заточенными специально под свой компилятор. По поводу сортировки я имел в виду этот случай.

[gribozavr]

Clang не поставляется со стандартной библиотекой C++. Clang может работать как с libstdc++, так и с libc++.

std::less_equal<int>() не даёт strict weak ordering, код некорректен. www.sgi.com/tech/stl/StrictWeakOrdering.html

[OldFisher]

Действительно, а я и не обратил внимание, что он использовал такое сравнение, просмотрел тему бегло. Что ж, значит, человек зря поднял панику. Хотя любопытно всё же, что гнусная реализация даже в таких условиях смогла выдать верный результат.

[Door]

Так и не понял, как работате first(std::get<Indices>(first_args)...)?

[OldFisher]

Это так называемая распаковка. При подстановке в Indices конкретного набора индексов, допустим {0, 1, 2} это выражение раскроется в first(std::get<0>(first_args), std::get<1>(first_args), std::get<2>(first_args))

[blaze79]

вот не очень понятен переход от
first(std::get(first_args)...)
к
first(std::forward(std::get(first_args))...)
чем первая конструкция плоха?

[OldFisher]

Первая конструкция плоха тем, что может «потерять» тип передаваемых аргументов. В первую очередь это относится к rvalue references: в функции с ними идёт работа как с обычными ссылками, и как обычные ссылки они передаются дальше. А значит, мы как минимум рискуем потерять семантику перемещения и связанные с этим оптимизации. Ну и просто есть риск запутаться в типах, вызывать не те перегрузки, которые задумывались. Чтобы избежать таких неприятностей, и используется механизм perfect forwarding.

[blaze79]

спасибо. все никак не приучу себя к rvalue references

[romy4]

Прикольно. Заметил, кстати, что на хабре нехватает хорошей статейки по всяким std::move, std::forward с каким-нибудь схематическим описанием механизма. Да и новых «умных» указателей. Может, я пропустил статью, конечно.