これはC ++ 11 forループの既知の落とし穴ですか？

Question 1

いくつかのメンバー関数で3つのdoubleを保持するための構造体があるとします。

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を文字列などで置き換える）：

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()) { ... }

前の2つの使用法の論理的な組み合わせのように見えますが、前の2つは完全に問題なく、この最後の使用法はぶら下がり参照を作成すると思います。

これは正しく、広く評価されていますか？
上記のどの部分が「悪い」部分であり、避けるべきですか？
for式で構築された一時がループの期間中存在するように、範囲ベースのforループの定義を変更することにより、言語は改善されますか？

Question 2

これは正しく、広く評価されていますか？

はい、あなたの物事の理解は正しいです。

上記のどの部分が「悪い」部分であり、それは避けるべきですか？

悪い点は、関数から返された一時変数への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();

しかし、あなたはまた不正確なことをすることができなくなります。

あるいは、コメントで提案されているように、右辺値の参照バージョンが参照ではなく値を返すようにすることができます。

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);代わりに使用できます。名前付き戻り値の最適化により、これはパフォーマンスの点で合理的に最適化されます。

Question 3

for（double x：Vector {1。、2.、3。}。normalize（））{...}

これは言語の制限ではなく、コードの問題です。式Vector{1., 2., 3.}は一時変数を作成しnormalizeますが、関数は左辺値参照を返します。式は左辺値であるため、コンパイラーはオブジェクトが生きていると想定しますが、それは一時オブジェクトへの参照であるため、完全な式が評価された後にオブジェクトが停止するため、ぶら下がり参照が残ります。

現在、現在のオブジェクトへの参照ではなく、値によって新しいオブジェクトを返すように設計を変更した場合、問題は発生せず、コードは期待どおりに動作します。

Question 4

私見、2番目の例にはすでに欠陥があります。修飾演算子が返すこと*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移動操作で行うことができます。