C++, почему ругается, я нуб штоле.

set( obj1.get);

Ты у гета скобки пропустил. Так можно делать в D, но в крестах - нет.

QString Cls1::get() const;

Здесь возвращается временный объект.

bool Cls2::set(QString& str);

А здесь не принимается временный объект, для него должно быть так:

bool Cls2::set(const QString& str);

Пардон, опечатка у меня тут, уже исправил. Это ж я вымышленный кусок сочинял. А в коде скобки есть.

Ты передаешь rvalue в функцию, принимающую lvalue

неконстантые ссылки возможны только на lvalue.

Есть одна оговорка, прафда офтопик. В винде (VS) можно и в неконстантые ссылки подавать временные объекты.

Да, но непонятно, что const то меняет?

Не стандарт, но все же.

Да, но непонятно, что const то меняет?

То что стандарт такое преобразование допускает допускает, а rvalue->non-cost-ref не позволяет. Вот и все.

Только сейчас понял что константной ссылке можно передавать rvalue, т.е. чистое значение.

const char& r = 'A';

Какова же семантика константной ссылки? Никак нагуглить не получается.

Какова же семантика константной ссылки?

Биндинг.

Какова же семантика константной ссылки? Никак нагуглить не получается.

GotW #88: A Candidate For the “Most Important const”

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

Временное значение или compile-time контсанта вполне может оказаться в той памяти, куда нельзя писать.

Поскольку на дворе 2016-ый, то предлагаю ТС-у освоить rvalue-reference. Вот, для затравки:

bool Cls2::set(QString &&str);

И кстати, в QString реализовано CoW, по этому обьекты QString — "дешёвые"

Время жизни продлевается, до скоупа константной ссылки.

Ага, и меня это страшно бесит :)

А потом приходят виндуз мены и говорят ололо этот ваш линух, там даже временный обьект по ссылке передать нельзя, это не я билд сломал а gcc :)

QString — «дешёвые»

Не дешевле ссылок одна фигня, иначе авторы сабжа не стали бы заморачиваться с передачей по константной ссылке во всём api.

И, до 11-ого стандарта многие реализации std::string тоже использовали cow, что нередко доставляло в многопоточных приложениях непосвященным товарищам.

QString — «дешёвые»

Не дешевле ссылок

Не спорю, в gcc, к примеру, ссылки реализованы через указатели (т.е. физически передается указатель через стек/регистры).

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

А QString'овский cow - thread safe?

Re-enterrant, но не thread-safe

Все равно непонятно, зачем языку ограничивать с неконстантной ссылкой то что не ограничено с константной ссылкой, ну и пусть временный объект изменяем, ведь все равно живет до области видимости ссылки. Какие объективные причины такого ограничения?

Если ты передаёшь, что то по неконстантной ссылке, то очевидно ты хочешь сохранить в нём некий стейт, т.е. как то изменить сий обьект.

Менять временный обьект смысла нет, т.к. ты не узнаешь, что он поменялся, ну только если через сайдэффекты от вызова методов оного обьекта опросить которые ты всё равно сможешь только имея на них ссылку переживающую временный обьект.

Вообщем, что бы не писать в /dev/null случайно.

По крайней мере, примерно так выкрутился сам Бьёрн(пруфов не будет, возможно это моё больное воображение).

Вообщем, что бы не писать в /dev/null случайно.

А потом они запилили rvalue refernces :D

Да, логично. Теперь дошло, спасибо. И спасибо всем кто помучился надо мной.

Это я к тому:

Но тот пост я написал к тому, что не стоит слишком переживать

По крайней мере я заметил нездоровую тенденцию (хотя, это возможно то, что до меня доходит прост) - писать всякий сервер сайд на Qt.

Что к чему - для меня загадка, а то что как минимум процентов 15 из тех кто этим занимается не знает про cow в QString и процентов 50 не понимает чем сиё может грозить при параллельной обработке сих обьектов это скорее всего печальная правда.

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

Неее, там же отжимается владение (ну по крайней мере такая семантика) ;)