Является ли это известной ловушкой C ++ 11 для циклов?

Представим, что у нас есть структура для хранения 3 двойников с некоторыми функциями-членами:

struct Vector {
  double x, y, z;
  // ...
  Vector &negate() {
    x = -x; y = -y; z = -z;
    return *this;
  }
  Vector &normalize() {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  // ...
};

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

Vector v = ...;
v.normalize().negate();

Или даже:

Vector v = Vector{1., 2., 3.}.normalize().negate();

Теперь, если бы мы предоставили функции begin () и end (), мы могли бы использовать наш вектор в цикле for нового стиля, скажем, чтобы перебрать 3 координаты x, y и z (вы, без сомнения, можете создать больше «полезных» примеров заменив Vector на, например, String):

Vector v = ...;
for (double x : v) { ... }

Мы даже можем:

Vector v = ...;
for (double x : v.normalize().negate()) { ... }

а также:

for (double x : Vector{1., 2., 3.}) { ... }

Однако следующее (как мне кажется) не работает:

for (double x : Vector{1., 2., 3.}.normalize()) { ... }

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

• Это правильно и широко ли это ценится?
• Какая часть из вышеперечисленного является «плохой», чего следует избегать?
• Можно ли улучшить язык, изменив определение цикла for на основе диапазона таким образом, чтобы временные структуры, созданные в выражении for, существовали в течение всего цикла?

Это правильно и широко ли это ценится?

Да, вы правильно понимаете.

Какая часть из вышеперечисленного является «плохой», чего следует избегать?

Плохая часть - это взять ссылку l-значения на временное значение, возвращаемое функцией, и привязать его к ссылке на r-значение. Это так же плохо:

auto &&t = Vector{1., 2., 3.}.normalize();

Время жизни временного Vector{1., 2., 3.}не может быть продлено, поскольку компилятор не знает, что возвращаемое значение normalizeссылается на него.

Можно ли улучшить язык, изменив определение цикла for на основе диапазона таким образом, чтобы временные структуры, созданные в выражении for, существовали в течение всего цикла?

Это было бы очень несовместимо с тем, как работает C ++.

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

Гораздо более разумным решением было бы каким-то образом сообщить компилятору, что возвращаемое значение функции всегда является ссылкой this, и поэтому, если возвращаемое значение привязано к временной расширяющейся конструкции, тогда оно расширит правильную временную. Однако это решение на уровне языка.

В настоящее время (если компилятор поддерживает это) вы можете сделать так, чтобы его normalize нельзя было вызвать временно:

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector &normalize() && = delete;
};

Это приведет Vector{1., 2., 3.}.normalize()к ошибке компиляции, при этом все v.normalize()будет работать нормально. Очевидно, вы не сможете делать такие правильные вещи, как это:

Vector t = Vector{1., 2., 3.}.normalize();

Но вы также не сможете делать неправильные вещи.

В качестве альтернативы, как предлагается в комментариях, вы можете сделать так, чтобы справочная версия rvalue возвращала значение, а не ссылку:

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector normalize() && {
     Vector ret = *this;
     ret.normalize();
     return ret;
  }
};

Если бы это Vectorбыл тип с реальными ресурсами для перемещения, вы могли бы использовать Vector ret = std::move(*this);вместо этого. Оптимизация именованного возвращаемого значения делает это достаточно оптимальным с точки зрения производительности.

for (double x: Vector {1., 2., 3.}. normalize ()) {...}

Это не ограничение языка, а проблема вашего кода. Выражение Vector{1., 2., 3.}создает временный объект, но normalizeфункция возвращает ссылку на lvalue . Поскольку выражение является lvalue , компилятор предполагает, что объект будет живым, но поскольку это ссылка на временный объект, объект умирает после вычисления полного выражения, поэтому остается висящая ссылка.

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

ИМХО, второй пример уже ошибочен. То, что модифицирующие операторы возвращаются *this, удобно, как вы упомянули: он позволяет связывать модификаторы. Его можно использовать для простой передачи результата модификации, но это чревато ошибками, так как это легко не заметить. Если я увижу что-то вроде

Vector v{1., 2., 3.};
auto foo = somefunction1(v, 17);
auto bar = somefunction2(true, v, 2, foo);
auto baz = somefunction3(bar.quun(v), 93.2, v.qwarv(foo));

Я бы не стал автоматически подозревать, что функции изменяются vкак побочный эффект. Конечно, могут , но это сбивает с толку. Так что, если бы я написал что-то подобное, я бы позаботился о том, чтобы это vоставалось неизменным. Для вашего примера я бы добавил бесплатные функции

auto normalized(Vector v) -> Vector {return v.normalize();}
auto negated(Vector v) -> Vector {return v.negate();}

а затем напишите петли

for( double x : negated(normalized(v)) ) { ... }

а также

for( double x : normalized(Vector{1., 2., 3}) ) { ... }

Это ИМО лучше читается и безопаснее. Конечно, для этого требуется дополнительная копия, однако для данных, размещенных в куче, это, вероятно, можно сделать с помощью дешевой операции перемещения C ++ 11.