При таком отношении к предметной части Вы обречены Ладно, считаем Вы пошутили. Lerp обычно синоним "линейной интерполяции"

C++ (Qt)
template<class T>
T Lerp( const T & a, cont T & b, double w )
{
  return a * (1.0 - w) + b * w;
}
 

Предполагается что T поддерживает арифметиику, но средствами языка это никак не утверждается
Ага, занимаются, хорошо, значит мои пожелания не так уж глупы 

Теперь понял, спасибо.

Ну типичный пример это QImage::mirrored, если объект временный, то можно использовать его внутренний буфер и не копировать всю картинку, а прямо внутри "отразить".
В отличие от неконстантного метода, такой подход позволяет писать более "функциональный" код - объекты не меняются, то есть нет побочных эффектов, но при этом всё достаточно эффективно - нужна старая картинка, ну получите копию (будет медленнее), не нужна - ну напишите std::move чтобы явно показать намерение "выкинуть" старую картинку - зато эффективно и не мутабельно при этом.

ViTech

Вроде бы там разговоры о таком синтаксисе идут

или

Но это не точно

Намного, это то что я хотел. Только в содержательной части насвистели, (b - a) тоже можно, но тогда так

C++ (Qt)
Arithmetic Lerp(const Arithmetic& a, const Arithmetic& b, double w)
{ return a + (b - a) * w; }
}

И боюсь что без этого ни до каких тонкостей языка дело не дойдет  

Что тут понятного, тут вообще ничего понятного нету.


Ага, а если не пометить, то экземпляр объекта не будет обязательно распределен в памяти?

Т.е. если я напишу Test t, то что, распределение объекта в памяти зависит от наличия & для метода? Какая ерунда. Я следую инструкции написаной вами выше, и просто продолжаю размышления (отнесём к неясности выражения мысли). Возможно вы имеете в виду такую временность, Test().funct() &&? Что тоже ерунда, т.к. вы утрверждаете что this внутри этого объекта может не существать (цитата: т.к. экземпляр такого объекта не обязательно имеет адрес в памяти). Размазан по регистрам? По каким правилам?  

Пока что для меня void T::method() && таки до сих пор не имеет смысла.

Ну как не имеет. Если брать что-то наподобии "чтобы было", когда нам нужно не задумываться и использовать единый подход, даже если это не имеет особого смысла.

Я тоже часто пишу "чтобы было"

Заметте, для компилятора вызов этих методов одинаков. Я то  на уровне программиста оптимизировал тип возвращаемого значения на ссылку, тем самым предотвратив копирование, надеясь, что это ограничит клиентов этого метода на уровне соглашения - не надо делать const_cast. Отвечаешь за последствия ты. Но компилятор то уж точно здесь ни при чем.

В вашем же случае я вообще не могу ничего оптимизировать. Это просто дублирование кода.

Никаких отличий для компилятора, как бы эти функции не были помечены  - & или && или просто классическая не имеют. Это просто перегрузка. Просто дополнительные квалификаторы. Реализация "временного объекта" берет на себя программист. И вызов std::move лишь вызовет соответствующум функцию, а она может просто копировать. Все.

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

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

Это я к чему эту дребень развел? Чтобы понять, на каком уровне мы находимся? На уровене компилятора? Для него нет оптимизации фунций с его точки зрения (& или && или const  в отличии от noexcept, finnaly....). Если на уровне программиста, то есть.

Так смысл в том, чтобы понять, где можно получить оптимизацию от вызовов:

void method()

и void method() &&.

Где, вызывая я один перегруженный метод, получу выгоду от вызова другого в разных условиях?
Ну хоть как то намекните.

Хочу заметить, тему я начал с хотелок конечно, но желание было чтобы компилятор хотя-бы const вызовы оптимизировал.

Я наверное неясно изъясняюсь. Но стремлюсь!

Вон Авваррон какие простыни пишет, никто с ним не спорит. Наверное думает, что что-то умное сказал, и все согласились.
На самом деле просто никто ничего не понял.

Ну или Igors - ну понятно! Ну, вам понятно, помогите  мне понять.

Тут же R/W пользователей с десяток, не больше. О чем общаться? Все в исходниках. Все всё прошли. Но какое желание держать лицо. Та давайте опустимся чуть ниже, все же фигню иногда делают. Все чего-то недопонимают. Но только попытка объяснить что либо вскрывает многие свои пробелы.

К примеру, я тоже доказывал что private virtual функция не имеет никакого смысла, думал - БОЖЕ, ЭТОЖЕ ОСНОВЫ.
Ну, правда, до сих пор смысла не понимаю, зачем они так сделали, но таки она работает, успешно компилируется и благодаря Маерсу (запретил бы его, как и Александреску) часто используется.