Ist dies eine bekannte Falle von C ++ 11 für Schleifen?

Stellen wir uns vor, wir haben eine Struktur für 3 Doubles mit einigen Mitgliedsfunktionen:

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;
  }
  // ...
};

Dies ist der Einfachheit halber ein wenig erfunden, aber ich bin sicher, Sie stimmen zu, dass es ähnlichen Code gibt. Mit den Methoden können Sie bequem verketten, zum Beispiel:

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

Oder auch:

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

Wenn wir nun die Funktionen begin () und end () bereitstellen, könnten wir unseren Vektor in einer neuen for-Schleife verwenden, beispielsweise um die 3 Koordinaten x, y und z zu durchlaufen (Sie können zweifellos weitere "nützliche" Beispiele erstellen durch Ersetzen von Vector durch zB String):

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

Wir können sogar:

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

und auch:

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

Das Folgende (es scheint mir) ist jedoch kaputt:

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

Während es wie eine logische Kombination der beiden vorherigen Verwendungen erscheint, denke ich, dass diese letzte Verwendung eine baumelnde Referenz erzeugt, während die vorherigen beiden völlig in Ordnung sind.

• Ist das richtig und weithin geschätzt?
• Welcher Teil des oben genannten ist der "schlechte" Teil, der vermieden werden sollte?
• Würde die Sprache verbessert, indem die Definition der bereichsbasierten for-Schleife so geändert wird, dass im for-Ausdruck konstruierte Temporäre für die Dauer der Schleife existieren?

Ist das richtig und weithin geschätzt?

Ja, dein Verständnis der Dinge ist richtig.

Welcher Teil des oben genannten ist der "schlechte" Teil, der vermieden werden sollte?

Der schlechte Teil besteht darin, eine L-Wert-Referenz auf eine von einer Funktion zurückgegebene temporäre Referenz zu nehmen und sie an eine R-Wert-Referenz zu binden. Es ist genauso schlimm wie das:

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

Die Vector{1., 2., 3.}Lebensdauer des Temporären kann nicht verlängert werden, da der Compiler keine Ahnung hat, dass der Rückgabewert von darauf normalizeverweist.

Würde die Sprache verbessert, indem die Definition der bereichsbasierten for-Schleife so geändert wird, dass im for-Ausdruck konstruierte Temporäre für die Dauer der Schleife existieren?

Das wäre sehr widersprüchlich mit der Funktionsweise von C ++.

Würde es bestimmte Fallstricke verhindern, die von Personen verursacht werden, die verkettete Ausdrücke auf Provisorien oder verschiedene Methoden zur verzögerten Bewertung von Ausdrücken verwenden? Ja. Es würde aber auch speziellen Compiler-Code erfordern und verwirrend sein, warum es nicht mit anderen Ausdruckskonstrukten funktioniert .

Eine viel vernünftigere Lösung wäre eine Möglichkeit, den Compiler darüber zu informieren, dass der Rückgabewert einer Funktion immer eine Referenz thisist. Wenn der Rückgabewert also an ein temporär erweiterendes Konstrukt gebunden ist, würde er den korrekten temporären Wert erweitern. Das ist jedoch eine Lösung auf Sprachebene.

Derzeit (wenn der Compiler dies unterstützt) können Sie es so gestalten, dass normalize es nicht vorübergehend aufgerufen werden kann :

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;
};

Dies führt Vector{1., 2., 3.}.normalize()zu einem Kompilierungsfehler und v.normalize()funktioniert einwandfrei. Offensichtlich können Sie solche Dinge nicht richtig machen:

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

Sie können aber auch keine falschen Dinge tun.

Alternativ können Sie, wie in den Kommentaren vorgeschlagen, festlegen, dass die rvalue-Referenzversion einen Wert anstelle einer Referenz zurückgibt:

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;
  }
};

Wenn Vectores sich um einen Typ mit tatsächlich zu verschiebenden Ressourcen handelt, können Sie ihn Vector ret = std::move(*this);stattdessen verwenden. Durch die Optimierung des benannten Rückgabewerts ist dies in Bezug auf die Leistung einigermaßen optimal.

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

Dies ist keine Einschränkung der Sprache, sondern ein Problem mit Ihrem Code. Der Ausdruck Vector{1., 2., 3.}erstellt eine temporäre, aber die normalizeFunktion gibt eine l-Wert-Referenz zurück . Da der Ausdruck ein Wert ist , geht der Compiler davon aus, dass das Objekt aktiv ist. Da es sich jedoch um eine Referenz auf ein temporäres Objekt handelt, stirbt das Objekt, nachdem der vollständige Ausdruck ausgewertet wurde, sodass Sie eine baumelnde Referenz erhalten.

Wenn Sie nun Ihr Design so ändern, dass ein neues Objekt nach Wert und nicht nach einem Verweis auf das aktuelle Objekt zurückgegeben wird, gibt es kein Problem und der Code funktioniert wie erwartet.

IMHO ist das zweite Beispiel bereits fehlerhaft. Dass die modifizierenden Operatoren zurückkehren, *thisist in der von Ihnen erwähnten Weise praktisch: Es ermöglicht die Verkettung von Modifikatoren. Es kann verwendet werden, um das Ergebnis der Änderung einfach weiterzugeben. Dies ist jedoch fehleranfällig, da es leicht übersehen werden kann. Wenn ich so etwas sehe

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));

Ich würde nicht automatisch vermuten, dass sich die Funktionen vals Nebeneffekt ändern . Natürlich könnten sie , aber es wäre verwirrend. Wenn ich also so etwas schreiben würde, würde ich sicherstellen, dass vdas konstant bleibt. Für Ihr Beispiel würde ich kostenlose Funktionen hinzufügen

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

und dann schreiben Sie die Schleifen

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

und

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

Das ist IMO besser lesbar und sicherer. Natürlich ist eine zusätzliche Kopie erforderlich, aber für Heap-zugewiesene Daten könnte dies wahrscheinlich in einem billigen C ++ 11-Verschiebungsvorgang erfolgen.