Например:
template <typename T>
struct foo
{
using bar = int;
};
// _Z3bazi
void baz(foo<int>::bar quux) {
}
template <typename T>
void baz(typename foo<T>::bar quux) {
}
// _Z3bazIiEvN3fooIT_E3barE
template void baz<int>(foo<int>::bar quux);
Почему в искаженной форме baz<int> вообще упоминается foo? Почему это не _Z3bazIiEvi?
Это, по-видимому, причина того, что предложение C++17 std::default_order<T> мертво в воде.
Проблема связана с конструкцией <unresolved-name> в ABI. Зачем нам когда-либо хотеть использовать неразрешенное имя? Все дело в сопоставлении объявлений и перегрузках. С++ 14 §14.5.6.1/3 примечания,
Два разных шаблона функций могут иметь идентичные типы возвращаемых функций и списки параметров функций, даже если разрешение перегрузки не может их различить.
У вас может быть другая функция в другом файле,
template <typename T>
void baz(int quux) { std::abort(); }
Хотя эта сигнатура не может мирно сосуществовать в одном и том же файле — она не может быть названа из-за двусмысленности перегрузки — она может существовать в другом файле, поэтому ее необходимо изменить.
(Даже такой уровень сосуществования не гарантируется стандартом для всех шаблонов. Вопрос QOI заключается в том, что компилятор использует точную форму объявления шаблона функции для выполнения сопоставления объявлений, так что копирование и вставка объявления в определение будет иметь тенденцию чтобы обеспечить точное совпадение, а не неожиданный конфликт с другим шаблоном функции, который разрешается в ту же сигнатуру (см. §14.5.6.1/5-6).
Что касается дождя на параде default_order, проблема заключается в том, что идентификаторы шаблонов неявно извлекают аргументы по умолчанию из шаблонов. Таким образом, пользователь может непреднамеренно иметь зависимое имя типа в подписи, просто упомянув std::set.
template <typenamte T> void baz(int) действительно разрешено в отдельной единице перевода? Я всегда предполагал, что это одна из тех уродливых вещей, не требующих диагностики. В частности, судя по всему, MSVC коверкает оба одинаково. Это действительно несовместимо?
- person Tavian Barnes; 20.10.2016
default_order, который предназначен для возврата чего-то другого.
- person T.C.; 21.10.2016
default_order функциональная эквивалентность имеет смысл только в контексте использования после любой настройки. Эквивалентность определяется при обработке деклараций; функциональная эквивалентность может быть определена при разрешении перегрузки. Оба всегда применимы, хотя они актуальны на разных этапах компиляции.
- person Potatoswatter; 21.10.2016
template<int I, int J> void f(A<I * J>); template<int I, int J> void f(A<I + J>); — это неправильно сформированный отчет о недоставке, что для меня не имеет никакого смысла.
- person T.C.; 21.10.2016
default_order может все же зависеть от специализаций default_order. Ваш пример, безусловно, является плохо сформированным отчетом о недоставке. Подключите I=0, J=0 и у вас есть заданный набор аргументов шаблона, оценка выражения приводит к тому же значению. Любая возникшая путаница является оправданием для чувствительности Itanium ABI к QOI.
- person Potatoswatter; 21.10.2016
I + J и I * J в моем понимании функционально не эквивалентны, потому что существуют некоторые наборы аргументов, для которых они не имеют одинакового значения (например, I=1, J=1). Вы читаете любое как ∃, я читаю как ∀. Действительно, при вашем прочтении даже пример двумя абзацами выше в [temp.over.link]/4 был бы неправильным отчетом о недоставке. Если бы это было намерением, я не могу представить, почему они не назвали бы это там.
- person T.C.; 21.10.2016
default_order специализациях. Диагностика отчета о недоставке применяется очень лениво во время компоновки, если вообще применяется, в то время как во время объявления шаблона вы можете мыслить более активно.
- person Potatoswatter; 21.10.2016
T, default_order_t<T> и std::less<T> одного и того же типа - а они не являются - тогда template<class T> void f(default_order_t<T>); и template<class T> void f(std::less<T>); являются отдельными шаблонами функций, которые не нарушают никаких правил в стандарте, и компилятор должен убедиться, что их специализации не соединены ошибочно.
- person T.C.; 21.10.2016
A+B с B+A). MSVC, кажется, идет с ∃ (или у него просто есть ошибка ABI), и перегрузочно-неоднозначные подписи могут конфликтовать в компоновщике. Ошибки в любом случае возникают естественным образом из-за компоновщика, а не из-за попытки фактически доказать эквивалентность. Например, MSVC обычно может давать одинаковые имена специализациям двух ваших шаблонов f, за исключением случаев, когда default_order является специализированным, тогда имена будут разными и ошибочной привязки не будет.
- person Potatoswatter; 21.10.2016
default_order не специализирована, то MSVC делает связь между этими двумя формами (предположим, что я прав; я не могу проверить, потому что у меня нет копии) . Это, вероятно, то, что вы действительно получаете. Но при их прочтении ∃ это будет неправильно сформированный NDR, поэтому связь, даже если она ошибочна, на самом деле в порядке.
- person Potatoswatter; 21.10.2016
foo можно специализировать так, чтобы он давал не-int типы, я с вами не согласен. Шаблоны функционально не эквивалентны AFAICS.
- person Johannes Schaub - litb; 14.05.2017
foo. Программе разрешено иметь только одну спецификацию члена для каждой специализации.
- person Potatoswatter; 15.05.2017
