LA
Собственно, если бы вызов был напрямую:
f(1), здесь 1 – тоже prvalueЯ уже добрался до этого
Однако здесь больше подходит это:
https://eel.is/c++draft/conv.lval#3.4
И я всё ещё не понимаю
Size: a a a
2021 March 06
PZ
Я полагаю о том, что будет результатом конвертации надо начинать думать только после того, как мы объявили конвертацию возможной. А мы её таковой вроде не объявили, поэтому и результат не вычисляем.
LA
Я полагаю о том, что будет результатом конвертации надо начинать думать только после того, как мы объявили конвертацию возможной. А мы её таковой вроде не объявили, поэтому и результат не вычисляем.
В смысле не объявили? Если бы у нас этой конвертации не было, у нас бы ни одна перегрузка вызваться не смогла бы. Здесь вызываются именно эти, потому что сначала идёт каст к првалью, а потом каст к флоату/инту. Который, между прочим, для првалью только и работает
PZ
А там случаем не это срабатывает?
https://en.cppreference.com/w/cpp/language/implicit_conversion#Temporary_materialization
https://en.cppreference.com/w/cpp/language/implicit_conversion#Temporary_materialization
PZ
Хотя это из С++17...
LA
А там случаем не это срабатывает?
https://en.cppreference.com/w/cpp/language/implicit_conversion#Temporary_materialization
https://en.cppreference.com/w/cpp/language/implicit_conversion#Temporary_materialization
Ну да, это. Только как это объясняет происходящее?
LA
Хотя это из С++17...
Там всё равно fold expression
LA
Что, как недавно выясняли ещё на С++ Сибирь, таки 17-ый стандарт :)
PZ
Ну да, это. Только как это объясняет происходящее?
1. Вызываем g(float&&, int&&)
2. Пытаемся вызвать f(float&&). Провал (нужно r-value, а мы передаем l-value)
3. Ищем другую перегрузку
4. Находим, что можно замутить temporary materialization от float к int&&
5. Вызываем f(int&&) для аргумента float&&
2. Пытаемся вызвать f(float&&). Провал (нужно r-value, а мы передаем l-value)
3. Ищем другую перегрузку
4. Находим, что можно замутить temporary materialization от float к int&&
5. Вызываем f(int&&) для аргумента float&&
PZ
Там всё равно fold expression
Это можно переписать на С++11
LA
1. Вызываем g(float&&, int&&)
2. Пытаемся вызвать f(float&&). Провал (нужно r-value, а мы передаем l-value)
3. Ищем другую перегрузку
4. Находим, что можно замутить temporary materialization от float к int&&
5. Вызываем f(int&&) для аргумента float&&
2. Пытаемся вызвать f(float&&). Провал (нужно r-value, а мы передаем l-value)
3. Ищем другую перегрузку
4. Находим, что можно замутить temporary materialization от float к int&&
5. Вызываем f(int&&) для аргумента float&&
Нет, temporary materialization к int&& идёт через два преобразования, к тому же, нет ни единой причины, чтобы после первого несоответствия перегрузка с float&& отпала, учитывая, что там нужно всего одно преобразование. Я об этом. Ну или нужны правила для разрешения перегрузки (которые, по-моему, сильно налажали в данном случае, если так)
LA
Как бы, если та перегрузка без преобразований отпала, то и эта должна была бы. А так, мы могли бы сравнить сколько преобразований надо для каждой, и о чудо! Для первой всего одно. Я не помню, конечно, наизусть все правила разрешения перегрузки, простите меня, но если она в данном случае работает не так... Ну, я всё ещё считаю это дырой в системе типов
LA
Это можно переписать на С++11
Да, то есть мы разобрались даже, что здесь не temporary materialization
PZ
Ну, то что его не было в стандарте, не значит, что оно не работало))) Этот код отлично компилируется в С++11
```
И оно дважды выводит "0", а не "0" и "1".
```
#include <iostream>```
using namespace std;
int main() {
int a = '0';
char const &b = a;
cout << b;
a++;
cout << b;
}
И оно дважды выводит "0", а не "0" и "1".
LA
Ну, то что его не было в стандарте, не значит, что оно не работало))) Этот код отлично компилируется в С++11
```
И оно дважды выводит "0", а не "0" и "1".
```
#include <iostream>```
using namespace std;
int main() {
int a = '0';
char const &b = a;
cout << b;
a++;
cout << b;
}
И оно дважды выводит "0", а не "0" и "1".
Меня это не удивляет, здесь всё логично. Если бы оно работало иначе, здесь были бы проблемы посерьёзнее, чем с системой типов, наверно. Впрочем, это сродни сломанным structured binding'ам
PZ
Как бы, если та перегрузка без преобразований отпала, то и эта должна была бы. А так, мы могли бы сравнить сколько преобразований надо для каждой, и о чудо! Для первой всего одно. Я не помню, конечно, наизусть все правила разрешения перегрузки, простите меня, но если она в данном случае работает не так... Ну, я всё ещё считаю это дырой в системе типов
Мне нужно еще несколько минут, чтобы подумать почему не срабатывает lvalue-to-rvalue conversion.
V
А че не так с "MIN_INT / -1"?
PZ
Просто если закомментировать одну из функций "f" будет ошибка компиляции. Что говорит о том, что lvalue float&& нельзя скастить в rvalue float&& )