Почему неконстантная ссылка не может быть привязана к временному объекту?

Из этого Статья в блоге Visual C ++ о ссылках на rvalue:

... C ++ не хочет, чтобы вы случайно изменили временные файлы, но прямой вызов неконстантной функции-члена для изменяемого rvalue является явным, поэтому он разрешен ...

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

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

Противодействие языку и обман компилятора редко решают проблемы - обычно они создают проблемы.

2) Я четко сформулировал цель: вам не разрешено изменять временные файлы, потому что это просто не имеет смысла (игнорируя ссылки C ++ 0x rvalue). На вопрос «тогда почему мне разрешено вызывать неконстантные члены?» хороший, но у меня нет лучшего ответа, чем тот, который я уже сказал выше.

3) Что ж, если я прав насчет x in X& x = getx().ref(); dying в конце утверждения, проблемы очевидны.

В любом случае, судя по вашему вопросу и комментариям, я не думаю, что даже эти дополнительные ответы вас удовлетворит. Вот последняя попытка / резюме: комитет C ++ решил, что нет смысла изменять временные файлы, поэтому они запретили привязку к неконстантным ссылкам. Может быть, была задействована какая-то реализация компилятора или исторические проблемы, я не знаю. Затем возник какой-то конкретный случай, и было решено, что, несмотря ни на что, они все же разрешат прямую модификацию через вызов неконстантного метода. Но это исключение - вам обычно не разрешается изменять временные файлы. Да, C ++ часто бывает таким странным.

В вашем коде getx() возвращает временный объект, так называемое «rvalue». Вы можете скопировать rvalue в объекты (также известные как переменные) или привязать их к константным ссылкам (что продлит их время жизни до конца жизни ссылки). Вы не можете привязать rvalue к неконстантным ссылкам.

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

g(getx()); // g() would modify an object without anyone being able to observe

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

X x1 = getx();
const X& x2 = getx(); // extend lifetime of temporary to lifetime of const reference

g(x1); // fine
g(x2); // can't bind a const reference to a non-const reference

Обратите внимание, что следующий стандарт C ++ будет включать ссылки на rvalue. Поэтому то, что вы называете ссылками, становится называться «ссылками lvalue». Вам будет разрешено связывать rvalue со ссылками на rvalue, и вы можете перегружать функции на "rvalue-ness":

void g(X&);   // #1, takes an ordinary (lvalue) reference
void g(X&&);  // #2, takes an rvalue reference

X x; 
g(x);      // calls #1
g(getx()); // calls #2
g(X());    // calls #2, too

Идея, лежащая в основе ссылок rvalue, заключается в том, что, поскольку эти объекты все равно умрут, вы можете воспользоваться этими знаниями и реализовать так называемую «семантику перемещения», определенный вид оптимизации:

class X {
  X(X&& rhs)
    : pimpl( rhs.pimpl ) // steal rhs' data...
  {
    rhs.pimpl = NULL; // ...and leave it empty, but deconstructible
  }

  data* pimpl; // you would use a smart ptr, of course
};


X x(getx()); // x will steal the rvalue's data, leaving the temporary object empty

Вы показываете, что цепочка операторов разрешена.

 X& x = getx().ref(); // OK

Выражение - «getx (). Ref ();» и это выполняется до завершения перед присвоением 'x'.

Обратите внимание, что getx () возвращает не ссылку, а полностью сформированный объект в локальном контексте. Объект временный, но не const, что позволяет вызывать другие методы для вычисления значения или возникновения других побочных эффектов.

// It would allow things like this.
getPipeline().procInstr(1).procInstr(2).procInstr(3);

// or more commonly
std::cout << getManiplator() << 5;

Лучший пример этого можно найти в конце этого ответа

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

Значение, возвращаемое функцией ref (), является действительной ссылкой, но метод не обращает внимания на срок службы возвращаемого объекта (поскольку он не может иметь эту информацию в своем контексте). Вы в основном только что сделали эквивалент:

x& = const_cast<x&>(getX());

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

Итак, единственный оставшийся вопрос: почему стандарт не разрешает ссылку на временные объекты для продления жизни объекта за пределами конца оператора?

Я считаю, что это потому, что в этом случае компилятору будет очень сложно правильно работать с временными объектами. Это было сделано для константных ссылок на временные библиотеки, поскольку это имеет ограниченное использование и, таким образом, вынуждает вас делать копию объекта, чтобы делать что-нибудь полезное, но предоставляет некоторые ограниченные функции.

Подумайте об этой ситуации:

int getI() { return 5;}
int x& = getI();

x++; // Note x is an alias to a variable. What variable are you updating.

Продление срока службы этого временного объекта будет очень запутанным.
Пока следующее:

int const& y = getI();

Дает вам код, который интуитивно понятен и понятен.

Если вы хотите изменить значение, вы должны вернуть значение переменной. Если вы пытаетесь избежать затрат на копирование объекта обратно из функции (поскольку кажется, что объект скопирован обратно (технически это так)). Тогда не беспокойтесь, компилятор очень хорош в «Оптимизации возвращаемого значения»

Почему обсуждается в C ++ FAQ (у меня выделено жирным шрифтом):

В C ++ неконстантные ссылки могут связываться с lvalue, а константные ссылки могут связываться с lvalue или rvalue, но нет ничего, что могло бы связываться с неконстантным rvalue. Это для защиты людей от изменения значений временных файлов, которые уничтожаются до того, как их новое значение может быть использовано. Например:

void incr(int& a) { ++a; }
int i = 0;
incr(i);    // i becomes 1
incr(0);    // error: 0 is not an lvalue

Если бы этот incr (0) был разрешен, либо какое-то временное, которое никто никогда не видел, было бы увеличено или, что еще хуже, значение 0 стало бы 1. Последнее звучит глупо, но на самом деле была такая ошибка в ранних компиляторах Fortran, которые устанавливали зарезервировать место в памяти для хранения значения 0.

Основная проблема в том, что

g(getx()); //error

является логической ошибкой: g изменяет результат getx(), но у вас нет возможности изучить измененный объект. Если g не нужно было изменять свой параметр, тогда ему не потребовалась бы ссылка lvalue, он мог бы взять параметр по значению или по константной ссылке.

const X& x = getx(); // OK

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

Однако сделать это невозможно.

X& x = getx(); // error

действителен, не делая g(getx()) действительным, чего разработчики языка пытались избежать в первую очередь.

g(getx().ref()); //OK

допустимо, потому что методы знают только о константе this, они не знают, вызываются ли они по lvalue или по rvalue.

Как всегда в C ++, у вас есть обходной путь для этого правила, но вы должны сообщить компилятору, что вы знаете, что делаете, явным образом:

g(const_cast<x&>(getX()));

Похоже, что на исходный вопрос о том, почему это запрещено, был дан четкий ответ: "потому что это, скорее всего, ошибка".

FWIW, я подумал, что покажу как это можно сделать, хотя я не думаю, что это хорошая техника.

Причина, по которой я иногда хочу передать временное значение методу, принимающему неконстантную ссылку, состоит в том, чтобы намеренно выбросить значение, возвращаемое по ссылке, которое вызывающему методу не важно. Что-то вроде этого:

// Assuming: void Person::GetNameAndAddr(std::string &name, std::string &addr);
string name;
person.GetNameAndAddr(name, string()); // don't care about addr

Как объяснялось в предыдущих ответах, это не компилируется. Но это компилируется и работает правильно (с моим компилятором):

person.GetNameAndAddr(name,
    const_cast<string &>(static_cast<const string &>(string())));

Это просто показывает, что вы можете использовать приведение, чтобы солгать компилятору. Очевидно, было бы намного чище объявить и передать неиспользуемую автоматическую переменную:

string name;
string unused;
person.GetNameAndAddr(name, unused); // don't care about addr

Этот метод действительно вводит ненужную локальную переменную в область действия метода. Если по какой-то причине вы хотите предотвратить его использование позже в методе, например, чтобы избежать путаницы или ошибки, вы можете скрыть его в локальном блоке:

string name;
{
    string unused;
    person.GetNameAndAddr(name, unused); // don't care about addr
}

- Крис

Зачем вам когда-нибудь нужен X& x = getx();? Просто используйте X x = getx(); и положитесь на RVO.

Злой обходной путь включает ключевое слово «изменяемый». На самом деле быть злом - это упражнение для читателя. Или посмотрите здесь: http://www.ddj.com/cpp/184403758

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

Любая ссылка, привязанная напрямую к временному объекту, продлит его жизнь [12.2.5]. С другой стороны, ссылка, инициализированная другой ссылкой, не (даже если она в конечном итоге такая же временная). Это имеет смысл (компилятор не знает, к чему в конечном итоге относится эта ссылка).

Но вся эта идея крайне сбивает с толку. Например. const X &x = X(); сделает временное продолжением до тех пор, пока указана x ссылка, но const X &x = X().ref(); НЕ будет (кто знает, что ref() фактически вернуло). В последнем случае деструктор для X вызывается в конце этой строки. (Это можно наблюдать с помощью нетривиального деструктора.)

В общем, это кажется запутанным и опасным (зачем усложнять правила, касающиеся времени жизни объектов?), Но, по-видимому, была потребность, по крайней мере, в константных ссылках, поэтому стандарт устанавливает для них такое поведение.

[Из комментария sbi]: обратите внимание, что тот факт, что привязка его к ссылке const увеличивает время жизни временного, является исключением, которое было добавлен намеренно (TTBOMK для возможности ручной оптимизации). Не было добавлено исключение для неконстантных ссылок, потому что связывание временной ссылки с неконстантной ссылкой, скорее всего, было ошибкой программиста.

Все временные файлы сохраняются до конца полного выражения. Однако, чтобы использовать их, вам понадобится трюк, как в случае с ref(). Это законно. Кажется, нет веских причин для перепрыгивания дополнительных пялец, кроме как напомнить программисту о том, что происходит что-то необычное (а именно, ссылочный параметр, изменения которого будут быстро потеряны).

[Еще один комментарий sbi] Причина, по которой Страуструп (в D&E) запрещает привязку значений rvalue к неконстантным ссылкам, заключается в том, что , если g () Алексея изменит объект (чего можно ожидать от функции, принимающей неконстантную ссылку), он изменит объект, который умирает, так что в любом случае никто не сможет получить измененное значение. Он говорит, что это, скорее всего, ошибка.

«Ясно, что временный объект не является постоянным в приведенном выше примере, потому что разрешены вызовы непостоянных функций. Например, ref () может изменить временный объект».

В вашем примере getX () не возвращает const X, поэтому вы можете вызвать ref () почти так же, как вы могли бы вызвать X (). Ref (). Вы возвращаете неконстантную ссылку и поэтому можете вызывать неконстантные методы, чего вы не можете сделать, так это присвоить ссылку неконстантной ссылке.

Наряду с комментарием SadSidos это делает ваши три пункта неверными.

У меня есть сценарий, которым я хотел бы поделиться, где я хотел бы сделать то, о чем просит Алексей. В подключаемом модуле Maya C ++ я должен проделать следующую махинацию, чтобы получить значение в атрибуте узла:

MFnDoubleArrayData myArrayData;
MObject myArrayObj = myArrayData.create(myArray);   
MPlug myPlug = myNode.findPlug(attributeName);
myPlug.setValue(myArrayObj);

Это утомительно писать, поэтому я написал следующие вспомогательные функции:

MPlug operator | (MFnDependencyNode& node, MObject& attribute){
    MStatus status;
    MPlug returnValue = node.findPlug(attribute, &status);
    return returnValue;
}

void operator << (MPlug& plug, MDoubleArray& doubleArray){
    MStatus status;
    MFnDoubleArrayData doubleArrayData;
    MObject doubleArrayObject = doubleArrayData.create(doubleArray, &status);
    status = plug.setValue(doubleArrayObject);
}

И теперь я могу написать код с начала поста как:

(myNode | attributeName) << myArray;

Проблема в том, что он не компилируется вне Visual C ++, потому что пытается привязать временную переменную, возвращаемую из | на ссылку MPlug оператора ‹*. Я хотел бы, чтобы это была ссылка, потому что этот код вызывается много раз, и я бы предпочел, чтобы MPlug не копировался так часто. Мне нужно, чтобы временный объект жил до конца второй функции.

Что ж, это мой сценарий. Просто подумал, что покажу пример, где хочется сделать то, что описывает Алексей. Я приветствую любую критику и предложения!

Спасибо.