Подтвердить что ты не робот

Разрешение перегрузки между объектом, ссылкой rvalue, константой ссылки

Учитывая все три функции, этот вызов неоднозначен.

int f( int );
int f( int && );
int f( int const & );

int q = f( 3 );

Удаление f( int ) приводит к тому, что Clang и GCC предпочитают ссылку rvalue по ссылке lvalue. Но вместо этого удаление двух опорных значений перегрузки в двусмысленности с помощью f( int ).

Разрешение перегрузки обычно выполняется с точки зрения строгого частичного упорядочения, но int представляется эквивалентным двум вещам, которые не эквивалентны друг другу. Какие здесь правила? Кажется, я вспоминаю отчет об ошибках.

Есть ли вероятность, что int && может быть предпочтительнее int в будущем стандарте? Ссылка должна привязываться к инициализатору, тогда как тип объекта не так ограничен. Поэтому перегрузка между T и T && может фактически означать "использовать существующий объект, если мне дали право собственности, иначе сделайте копию". (Это похоже на чистый проход по значению, но экономит накладные расходы на перемещение.) Поскольку эти компиляторы в настоящее время работают, это необходимо сделать, перегружая T const & и T && и явно копируя. Но я даже не уверен, что это стандартно.

4b9b3361

Ответ 1

Каковы правила здесь?

Поскольку существует только один параметр, правило состоит в том, что одна из трех жизнеспособных инициализаций параметров этого параметра должна быть лучше совпадения, чем и двух других. Когда сравниваются две инициализации, либо одна лучше другой, либо ни одна из них не лучше (они неразличимы).

Без специальных правил о привязке прямых ссылок все три упомянутые инициализации были бы неразличимы (во всех трех сравнениях).

Специальные правила о привязке прямых ссылок делают int&& лучше, чем const int&, но ни один из них не лучше или хуже, чем int. Поэтому лучшего совпадения нет:

S1    S2
int   int&&         indistinguishable
int   const int&    indistinguishable
int&& const int&    S1 better

int&& лучше, чем const int& из-за 13.3.3.2:

S1 и S2 являются привязками привязки (8.5.3), и ни один из них не ссылается на неявный параметр объекта нестатической функции-члена, объявленной без реф-определителя, а S1 связывает ссылку rvalue с rvalue, а S2 связывает значение lvalue ссылка.

Но это правило не применяется, когда одна из инициализаций не является привязкой ссылки.

Есть ли шанс, что int && может быть предпочтительнее, чем int в будущем стандарте? Ссылка должна привязываться к инициализатору, тогда как тип объекта не так ограничен. Таким образом, перегрузка между T и T && может эффективно означать "использовать существующий объект, если мне дано право собственности, иначе сделайте копию".

Вы предлагаете сделать привязку привязки лучшим совпадением, чем привязка без ссылки. Почему бы не опубликовать свою идею будущие предложения isocpp. SO не является лучшим для субъективного обсуждения/мнения.