Copia costruttore e = sovraccarico dell'operatore in C ++: è possibile una funzione comune?

Poiché un costruttore di copie

MyClass(const MyClass&);

e un sovraccarico dell'operatore =

MyClass& operator = (const MyClass&);

hanno più o meno lo stesso codice, lo stesso parametro e differiscono solo al ritorno, è possibile avere una funzione comune da utilizzare per entrambi?

Sì. Ci sono due opzioni comuni. Uno - che è generalmente sconsigliato - è chiamare operator=esplicitamente il dal costruttore di copie:

MyClass(const MyClass& other)
{
    operator=(other);
}

Tuttavia, fornire un bene operator=è una sfida quando si tratta di affrontare il vecchio stato e le questioni derivanti dall'assegnazione di sé. Inoltre, tutti i membri e le basi vengono inizializzati per impostazione predefinita per primi anche se devono essere assegnati a da other. Questo potrebbe non essere nemmeno valido per tutti i membri e le basi e anche dove è valido è semanticamente ridondante e può essere praticamente costoso.

Una soluzione sempre più diffusa consiste nell'implementazione operator=utilizzando il costruttore di copie e un metodo di scambio.

MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    swap(tmp);
    return *this;
}

o anche:

MyClass& operator=(MyClass other)
{
    swap(other);
    return *this;
}

Una swapfunzione è tipicamente semplice da scrivere in quanto si limita a scambiare la proprietà degli interni e non deve ripulire lo stato esistente o allocare nuove risorse.

I vantaggi dell'idioma di copia e scambio sono che è automaticamente sicuro per l'autoassegnazione e, a condizione che l'operazione di scambio non avvenga, è anche fortemente sicuro rispetto alle eccezioni.

Per essere assolutamente sicuro rispetto alle eccezioni, un operatore di assegnazione scritta "manuale" deve in genere allocare una copia delle nuove risorse prima di disallocare le vecchie risorse dell'assegnatario in modo che se si verifica un'eccezione nell'allocazione delle nuove risorse, il vecchio stato può ancora essere restituito a . Tutto questo viene fornito gratuitamente con il copy-and-swap, ma in genere è più complesso, e quindi soggetto a errori, da fare da zero.

L'unica cosa a cui fare attenzione è assicurarsi che il metodo di scambio sia un vero scambio, e non quello predefinito std::swapche utilizza il costruttore di copia e l'operatore di assegnazione stesso.

In genere swapviene utilizzato un memberwise . std::swapfunziona ed è garantito "no-throw" con tutti i tipi di base e i tipi di puntatore. La maggior parte dei puntatori intelligenti può anche essere scambiata con una garanzia di non lancio.

Il costruttore di copie esegue la prima inizializzazione degli oggetti che erano la memoria non elaborata. L'operatore di assegnazione, OTOH, sovrascrive i valori esistenti con quelli nuovi. Più spesso che mai, ciò comporta l'eliminazione delle vecchie risorse (ad esempio la memoria) e l'allocazione di nuove.

Se c'è una somiglianza tra i due, è che l'operatore di assegnazione esegue la distruzione e la costruzione di copie. Alcuni sviluppatori erano soliti implementare effettivamente l'assegnazione mediante distruzione sul posto seguita dalla costruzione di copie di posizionamento. Tuttavia, questa è una molto cattiva idea. (E se questo è l'operatore di assegnazione di una classe base che ha chiamato durante l'assegnazione di una classe derivata?)

Quello che di solito è considerato l'idioma canonico al giorno d'oggi sta usando swapcome suggerito da Charles:

MyClass& operator=(MyClass other)
{
    swap(other);
    return *this;
}

Questo utilizza la costruzione della copia (nota che otherviene copiato) e la distruzione (viene distrutto alla fine della funzione) - e li usa anche nel giusto ordine: costruzione (potrebbe fallire) prima della distruzione (non deve fallire).

Qualcosa mi dà fastidio:

MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    swap(tmp);
    return *this;
}

Primo, leggere la parola "scambia" quando la mia mente pensa "copia" irrita il mio buon senso. Inoltre, metto in dubbio l'obiettivo di questo trucco stravagante. Sì, eventuali eccezioni nella costruzione delle nuove risorse (copiate) dovrebbero verificarsi prima dello scambio, il che sembra un modo sicuro per assicurarsi che tutti i nuovi dati siano riempiti prima di renderli disponibili.

Va bene. Allora, che dire delle eccezioni che si verificano dopo lo scambio? (quando le vecchie risorse vengono distrutte quando l'oggetto temporaneo esce dall'ambito) Dal punto di vista dell'utente dell'assegnazione, l'operazione è fallita, tranne che non l'ha fatto. Ha un enorme effetto collaterale: la copia è realmente avvenuta. Solo una pulizia delle risorse non è riuscita. Lo stato dell'oggetto di destinazione è stato alterato anche se l'operazione sembra dall'esterno non riuscita.

Quindi, propongo invece di "scambiare" per fare un "trasferimento" più naturale:

MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    transfer(tmp);
    return *this;
}

C'è ancora la costruzione dell'oggetto temporaneo, ma la prossima azione immediata è liberare tutte le risorse correnti della destinazione prima di spostare (e annullare in modo che non vengano liberate due volte) le risorse della sorgente su di esso.

Invece di {costruisci, sposta, distruggi}, propongo {costruisci, distruggi, sposta}. La mossa, che è l'azione più pericolosa, è quella presa per ultima dopo che tutto il resto è stato risolto.

Sì, il fallimento della distruzione è un problema in entrambi gli schemi. I dati sono danneggiati (copiati quando non pensavi che fossero) o persi (liberati quando non pensavi che lo fossero). Perso è meglio che danneggiato. Nessun dato è meglio di dati errati.

Trasferisci invece di scambiare. Questo è comunque il mio suggerimento.