Discussion :

[damien.flament]

Bonjour,

Il est dit dans la FAQ C++ qu'une version correcte lors de la surcharge de l'opérateur d'assignation est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
MaClasse& MaClasse::operator =(const MaClasse& Other)
{
    // Utilisation du constructeur par copie pour copier la ressource MaClasse
    MaClasse Temp(Other);
 
    // Réaffectation : on prend les nouvelles données dans Temp, et on lui
    // donne les données à détruire en échange
    std::swap(Temp.Ressource, this->Ressource);
 
    return *this;
} // A la fin de la fonction, Temp sera détruit automatiquement
  // et son destructeur désallouera correctement la ressource

Ne serait-il pas plus simple de procéder comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
MaClasse& MaClasse::operator =(MaClasse Other)
{
    // Réaffectation : on prend les nouvelles données dans Other, et on lui
    // donne les données à détruire en échange
    std::swap(Other.Ressource, this->Ressource);
 
    return *this;
} // A la fin de la fonction, Other sera détruit automatiquement
  // et son destructeur désallouera correctement la ressource

Plus besoin d'appeler le constructeur par recopie, cela est fait automatiquement puisque l'objet à affecté est maintenant passé par valeur. Il est également détruit automatiquement.

[Goten]

Si, ça a même un nom le copy eliding. (la faq est un peu vieille sur certains pointss)

[koala01]

Salut,

Les deux codes sont effectivement totalement identiques en ce qui concerne leur exécution...

La seule différence tient en réalité dans le fait que l'un est plus verbeux (et donc plus facile à appréhender ) que l'autre

Je crois que le principale problème auquel on a été confronté au moment d'écrire la FAQ, c'est que, comme les deux méthodes sont totalement équivalentes (exception faite de la vervosité), il a "bien fallu" choisir de n'en présenter qu'un, car il est beaucoup plus difficile de prétendre qu'une manière de faire est idéale si... on présente deux manières de s'y prendre

A l'époque (pourtant pas si lointaine ) où la faq a été mise à jour, le débat n'était pas encore tranché, et on a donc préféré garder "la manière antique de faire", voilà tout

[Goten]

Non c'est pas identique.

la version T& operator=(T t); est plus rapide dans certains cas grâce à la copy-elision.

Ie dans ce genre de situation :

T makeT();
T t;
t = makeT();

[Aleph69]

Bonsoir,

la version T& operator=(T t); est plus rapide dans certains cas grâce à la copy-elision, i.e. dans ce genre de situation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
T makeT();
T t;
t = makeT();

Je ne comprends pas pourquoi

[Goten]

Parce que c'est la régle (et c'est plutôt "logique"), la copy elision ne se fait pas si la rvalue est bindé à une référence. (ce qui est le cas).

Norme 12.8 p15

This elision of copy operations is permitted in the
following circumstances (which may be combined to eliminate multiple copies):
...
when a temporary class object that has not been bound to a reference (12.2) would be copied to a class
object with the same cv-unqualified type, the copy operation can be omitted by constructing the temporary
object directly into the target of the omitted copy

D'où l'intérêt de passer par valeur, ça permet de profiter dans certains cas de la copy-elision.

[Flob90]

Pour préciser ce qu'il se passe dans l'exemple de Goten, dans le cas où l'on utilise la forme avec const T& :
- make construit un T
- passage par référence donc aucune construction
- construction d'une copie dans le corps de l'opérateur d'affectation
- ...

Dans le second cas, T, on s'attendrait à
- make construit un T
- passage par copie, donc construction d'une copie
- ...

Mais d'après la copy-elision permet dans certains cas (cf la norme au passage cité par Goten), c'éviter la seconde copie, on a donc
- make construit un T directement dans l'appel de la fonction.

Au final on gagne un constructeur.

[Luc Hermitte]

Dans l'absolu, il faudrait en effet prendre une copie.
Mais je pense que pour des raisons d'harmonie la version avec const& est restée.
(De plus, l'harmonie est plus facile à vendre dans des équipes hétérogènes)

[Joel F]

Ca dépend aussi de la politique d'exception-safety et de potentielles optimisations plus fortes que la copy elision (genre des conteneurs avec un resize/copy etc).

L'avantage du copy-by-swap, c'est qu'il fournit une strong garantee sur les exceptions.

[Flob90]

J'ai surment raté quelque chose, mais les deux code ont exactement la même resistance aux exceptions, non ?