Це відомий підводний камінь 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 (), ми могли б використовувати наш Vector у новому стилі for loop, скажімо, цикл над 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, існували протягом усього циклу?

Це правильно і широко цінується?

Так, ваше розуміння речей правильне.

Яка частина вищезазначеного є «поганою» частиною, якої слід уникати?

Погана частина - це посилання на значення l на тимчасове повернення з функції та прив’язка його до посилання на значення r. Це так само погано, як це:

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

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

Чи можна вдосконалити мову, змінивши визначення циклу, заснованого на діапазоні, таким чином, щоб тимчасові структури, побудовані у виразі 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);. Оптимізація іменованої віддачі робить це досить оптимальним з точки зору продуктивності.

для (подвійний x: Вектор {1., 2., 3.}. normalize ()) {...}

Це не обмеження мови, а проблема з вашим кодом. Вираз Vector{1., 2., 3.}створює тимчасовий, але normalizeфункція повертає посилання lvalue . Оскільки вираз є значенням l , компілятор припускає, що об'єкт буде живим, але оскільки це посилання на тимчасовий, об'єкт вмирає після обробки повного виразу, тому вам залишається бовтається посилання.

Тепер, якщо ви зміните свій дизайн, щоб повернути новий об’єкт за значенням, а не за посиланням на поточний об’єкт, тоді проблеми не виникне, і код працюватиме належним чином.

ІМХО, другий приклад вже недосконалий. Те, що модифікуючі оператори повертають *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}) ) { ... }

Це IMO краще читається, і це безпечніше. Звичайно, для цього потрібна додаткова копія, однак для даних, розподілених до купи, це, швидше за все, може бути зроблено в дешевій операції переміщення C ++ 11.