Su attuazione std :: scambio in termini di assegnazione di movimento e spostare costruttore

Question

Ecco una possibile definizione di std::swap:

template<class T> 
void swap(T& a, T& b) { 
    T tmp(std::move(a)); 
    a = std::move(b); 
    b = std::move(tmp); 
} 

Credo che

1. std::swap(v,v) è garantito per avere alcun effetto e
2. std::swap può essere implementato come sopra.

La seguente citazione mi sembra implicare che queste convinzioni siano contraddittorie.

17.6.4.9 Argomenti delle funzioni [res.on.arguments]

1 Ciascuno dei seguenti si applica a tutti gli argomenti a funzioni definite nella libreria standard C++, se non diversamente specificato.

...

• Se un argomento funzione si lega ad un parametro di riferimento rvalue, l'applicazione può supporre che questo parametro è un riferimento unico per questo argomento. [Nota: se il parametro è un parametro generico del modulo & & e un lvalue di tipo A è associato, l'argomento si lega a un riferimento di lv lvalue (14.8.2.1) e pertanto non è coperto dalla precedente frase . - nota finale] [Nota: se un programma esegue un lvalue su un valore durante il passaggio di tale valore a una funzione di libreria (ad esempio tramite chiamando la funzione con l'argomento move (x)), il programma è chiedendo effettivamente tale funzione a tratta quel lvalue come temporaneo. L'implementazione è gratuita per ottimizzare i controlli di aliasing che potrebbero essere necessari se l'argomento era un lvalue. -endnote]

(grazie a Howard Hinnant per providing the quote)

Lasciate v essere un oggetto di un certo tipo mobile tratto dalla Standard Template Library e considerano la chiamata std::swap(v, v). Nella riga a = std::move(b); sopra, è il caso all'interno di T::operator=(T&& t) quello this == &b, quindi il parametro è non un riferimento univoco. Si tratta di una violazione del requisito sopra riportato, pertanto la riga a = std::move(b) richiama il comportamento non definito quando viene chiamato da std::swap(v, v).

Qual è la spiegazione qui?

Answer 1

credo che non è una definizione valida di std::swap perché std::swap è definito a prendere i riferimenti lvalue, non i riferimenti rvalue (20.2.2 [utility.swap])

Answer 2

Poi l'espressione a = std::move(b); viene eseguito, l'oggetto è già vuoto, in uno stato in cui solo la distruzione è ben definita. Questo sarà effettivamente un no-op, poiché l'oggetto sul lato sinistro e destro è già vuoto.Lo stato dell'oggetto dopo la mossa è ancora sconosciuto ma distruttibile. La prossima istruzione sposta il contenuto da tmp e riporta l'oggetto a uno stato noto.

Answer 3

[res.on.arguments] è un'istruzione su come il client deve utilizzare std :: lib. Quando il client invia un xvalue a una funzione std :: lib, il client deve essere disposto a fingere che xvalue sia realmente un valore di prval, e si aspetta che std :: lib ne sfrutti.

Tuttavia, quando il client chiama std :: swap (x, x), il client non invia un xvalue a una funzione std :: lib. Invece è l'implementazione che sta facendo. E così l'onere è sull'implementazione per far funzionare std :: swap (x, x).

Detto questo, lo std ha dato al implementatore una garanzia: X deve soddisfare MoveAssignable. Anche se in uno stato spostato da, il client deve assicurarsi che X sia MoveAssignable. Inoltre, l'implementazione di std::swap non interessa molto a quale auto-spostamento-assegnazione, purché non sia un comportamento non definito per X. I.e. finché non si arresta in modo anomalo.

a = std::move(b); 

Quando & a == & b, sia l'origine e destinazione di questo compito hanno un valore specificato (spostato-da). Questo può essere un no-op o può fare qualcos'altro. Finché non si blocca, std :: swap funzionerà correttamente. Questo perché nella riga successiva:

b = std::move(tmp); 

qualsiasi valore è andato in a dalla riga precedente sta per essere dato un nuovo valore da tmp. E tmp ha il valore originale di a. Quindi oltre a bruciare un sacco di cicli cpu, swap(a, a) è un no-op.

Aggiorna

Il latest working draft, N4618 è stato modificato per indicare chiaramente che nei requisiti MoveAssignable l'espressione:

t = rv 

(dove rv è un rvalue), t deve essere solo il valore equivalente di rv prima dell'assegnazione se t e rv non fanno riferimento allo stesso oggetto. E a prescindere, lo stato di rv non è specificato dopo l'assegnazione. C'è una nota aggiuntiva per ulteriori chiarimenti:

rv deve ancora soddisfare i requisiti del componente libreria che lo sta utilizzando, anche se non t e rv si riferiscono allo stesso oggetto.

Answer 4

Sono d'accordo con la tua analisi, e infatti la libstdC++ Debug Mode ha un'affermazione che il fuoco sull'auto-swap di contenitori standard:

#include <vector> 
#include <utility> 

struct S { 
    std::vector<int> v; 
}; 

int main() 
{ 
    S s; 
    std::swap(s, s); 
} 

Il tipo di involucro S è necessario perché lo scambio direttamente vettore usa la specializzazione che chiama vector::swap() e quindi non usa il generico std::swap, ma S userà quello generico e quando compilato come C++ 11 che si tradurrà in un'assegnazione auto-spostamento del membro vettoriale, che abortirà :

/home/toor/gcc/4.8.2/include/c++/4.8.2/debug/vector:159:error: PST. 

Objects involved in the operation: 
sequence "this" @ 0x0x7fffe8fecc00 { 
    type = NSt7__debug6vectorIiSaIiEEE; 
} 
Aborted (core dumped) 

(Non so cosa "PST" dovrebbe significare lì! Penso che ci sia qualcosa di sbagliato nell'installazione con cui l'ho provato.)

Credo che il comportamento di GCC qui sia conforme, perché lo standard dice che l'implementazione può assumere che l'auto-spostamento-assegnazione non avviene mai, quindi l'affermazione non fallirà mai in un programma valido.

Tuttavia, sono d'accordo con Howard che questo ha bisogno di funzionare (e può essere fatto funzionare senza troppi problemi - per libstdC++ abbiamo solo bisogno di eliminare l'asserzione della modalità di debug!), E quindi dobbiamo correggere lo standard per fare un'eccezione per l'auto-spostamento, o almeno per l'auto-scambio. Mi è stato promesso di scrivere un articolo su questo argomento da tempo, ma non l'ho ancora fatto.

Credo che da quando ho scritto la sua risposta, Howard ora accetta che ci sia un problema con l'attuale formulazione nello standard, e abbiamo bisogno di correggerlo per impedire a libstdC++ di fare quella asserzione che fallisce.