È questo un noto errore di C ++ 11 per i cicli?

Immaginiamo di avere una struttura per contenere 3 doppie con alcune funzioni membro:

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

Questo è un po 'artificioso per semplicità, ma sono sicuro che sei d'accordo sul fatto che un codice simile sia disponibile. I metodi ti consentono di concatenare comodamente, ad esempio:

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

O anche:

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

Ora, se fornissimo le funzioni begin () e end (), potremmo usare il nostro Vector in un nuovo stile del ciclo for, ad esempio per eseguire il ciclo sulle 3 coordinate x, yez (senza dubbio puoi costruire esempi più "utili" sostituendo Vector con es. String):

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

Possiamo anche fare:

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

e anche:

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

Tuttavia, il seguente (mi sembra) non funziona:

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

Anche se sembra una combinazione logica dei due usi precedenti, penso che quest'ultimo utilizzo crei un riferimento penzolante mentre i due precedenti sono completamente a posto.

• È corretto e ampiamente apprezzato?
• Quale parte di quanto sopra è la parte "cattiva", che dovrebbe essere evitata?
• Il linguaggio sarebbe migliorato cambiando la definizione del ciclo for basato su intervallo in modo tale che i provvisori costruiti nell'espressione for esistano per la durata del ciclo?

È corretto e ampiamente apprezzato?

Sì, la tua comprensione delle cose è corretta.

Quale parte di quanto sopra è la parte "cattiva", che dovrebbe essere evitata?

La parte negativa è prendere un riferimento a un valore l a un valore temporaneo restituito da una funzione e associarlo a un riferimento a un valore r. È altrettanto brutto come questo:

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

La Vector{1., 2., 3.}durata del temporaneo non può essere estesa perché il compilatore non ha idea che il valore restituito da vi faccia normalizeriferimento.

Il linguaggio sarebbe migliorato cambiando la definizione del ciclo for basato su intervallo in modo tale che i provvisori costruiti nell'espressione for esistano per la durata del ciclo?

Ciò sarebbe altamente incoerente con il funzionamento del C ++.

Impedirebbe certi trucchi fatti da persone che usano espressioni concatenate su provvisori o vari metodi di valutazione pigra per le espressioni? Sì. Ma richiederebbe anche codice del compilatore per casi speciali, oltre a creare confusione sul motivo per cui non funziona con altri costrutti di espressione.

Una soluzione molto più ragionevole potrebbe essere un modo per informare il compilatore che il valore restituito di una funzione è sempre un riferimento a this, e quindi se il valore restituito è associato a un costrutto di estensione temporanea, estenderebbe il valore temporaneo corretto. Questa è una soluzione a livello di lingua.

Attualmente (se il compilatore lo supporta), puoi farlo in modo che normalize non possa essere chiamato temporaneamente:

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

Ciò causerà Vector{1., 2., 3.}.normalize()un errore di compilazione, mentre v.normalize()funzionerà bene. Ovviamente non sarai in grado di fare cose corrette come questa:

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

Ma non sarai nemmeno in grado di fare cose sbagliate.

In alternativa, come suggerito nei commenti, puoi fare in modo che la versione di riferimento rvalue restituisca un valore anziché un riferimento:

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

Se Vectorfosse un tipo con risorse effettive da spostare, potresti Vector ret = std::move(*this);invece usare . L'ottimizzazione del valore di ritorno denominato lo rende ragionevolmente ottimale in termini di prestazioni.

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

Questa non è una limitazione della lingua, ma un problema con il tuo codice. L'espressione Vector{1., 2., 3.}crea una temporanea, ma la normalizefunzione restituisce un lvalue-riferimento . Poiché l'espressione è un lvalue , il compilatore presume che l'oggetto sarà attivo , ma poiché si tratta di un riferimento a un elemento temporaneo, l'oggetto muore dopo la valutazione dell'espressione completa, quindi rimane un riferimento sospeso.

Ora, se si modifica la progettazione per restituire un nuovo oggetto in base al valore anziché un riferimento all'oggetto corrente, non ci sarebbero problemi e il codice funzionerebbe come previsto.

IMHO, il secondo esempio è già difettoso. Il fatto che gli operatori di modifica restituiscano *thisè conveniente nel modo in cui hai accennato: consente il concatenamento di modificatori. Esso può essere utilizzato per la semplice consegna sul risultato della modifica, ma facendo questo è soggetto ad errori, perché può facilmente essere trascurato. Se vedo qualcosa di simile

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

Non sospetterei automaticamente che le funzioni vengano modificate vcome effetto collaterale. Certo, potrebbero , ma sarebbe fonte di confusione. Quindi, se dovessi scrivere qualcosa del genere, mi assicurerei che vrimanga costante. Per il tuo esempio, aggiungerei funzioni gratuite

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

e poi scrivi i loop

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

e

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

Questo è IMO più leggibile ed è più sicuro. Naturalmente, richiede una copia extra, tuttavia per i dati allocati nell'heap ciò potrebbe essere probabilmente fatto in un'operazione di spostamento C ++ 11 economica.