Nous avons déjà un premier aperçu des possibilités offertes par auto_ptr, mais nous n’en sommes qu’au début : voyons maintenant à quel point il est pratique d’uti-liser des auto_ptr lors d’appels de fonctions, qu’il s’agisse d’en passer en paramètre ou bien d’en recevoir en valeur de retour.
Pour cela, intéressons-nous en premier lieu à ce qui se passe lorsqu’on copie un
auto_ptr : l’opération de copie d’un auto_ptr source, pointant vers un objet donné, vers un auto_ptr cible, a pour effet de transférer l’appartenance de l’objet pointé du pointeur source au pointeur cible. Le principe sous-jacent est qu’un objet pointé ne peut appartenir qu’à un seul auto_ptr à la fois. Si l’auto_ptr cible pointait déjà vers un objet, cet objet est désalloué au moment de la copie. Une fois la copie effectuée, l’objet initial appartiendra donc à l’auto_ptr cible, tandis que l’auto_ptr source sera réinitialisé et ne pourra plus être utilisé pour faire référence à cet objet. C’est l’auto_ptr cible qui, le moment venu, détruira l’objet initial :
// Exemple 5: Transfert d’un objet // d’un auto_ptr à un autre //
void f() {
auto_ptr<T> pt1( new T );
auto_ptr<T> pt2;
pt1->DoSomething(); // OK
pt2 = pt1; // Maintenant, c’est pt2 qui contrôle // l’objet T
pt2->DoSomething(); // OK
} // Lorsque la fonction se termine, le destructeur // de pt2 détruit l’objet; pt1 ne fait rien
Faites bien attention de ne pas utiliser un auto_ptr auquel plus aucun objet n’appartient :
// Exemple 6: Utilisation d’un auto_ptr ne contrôlant rien // À NE PAS FAIRE !
//
void f() {
auto_ptr<T> pt1( new T );
auto_ptr<T> pt2;
pt2 = pt1; // Maintenant, pt2 contrôle l’objet alloué // pt1 ne contrôle plus aucun objet.
pt1->DoSomething();
// Erreur : utilisation d’un pointeur nul ! }
Voyons maintenant à quel point auto_ptr est bien adapté à l’implémentation de sources et de puits. Une « source » est une fonction qui crée un nouvel objet puis abandonne le contrôle de cet objet à l’appelant. Un « puits » est une fonction qui, à l’inverse, prend le contrôle d’un objet existant (et généralement, détruit cet objet après l’avoir utilisé).
Dans l’implémentation de sources et de puits, plutôt que d’utiliser de simples pointeurs pointant vers l’objet manipulé, il peut s’avérer très pratique de renvoyer (resp. prendre en paramètre) un pointeur intelligent rattaché à cet objet.
Ceci nous amène finalement aux premières lignes de code de l’énoncé de notre problème :
auto_ptr<T> source() {
return auto_ptr<T>( new T(1) );
}
void sink( auto_ptr<T> pt ) { }
Non seulement ces lignes sont tout à fait correctes, mais, de plus, elles sont très élégantes :
1. La manière avec laquelle la fonction source() crée un nouvel objet et le renvoie à l’appelant est parfaitement sécurisée : l’auto_ptr assure que l’objet alloué sera détruit en temps voulu. Même si, par erreur, l’appelant ignore la valeur de retour de la fonction, l’objet sera également correctement détruit. Voir également le pro-blème n° 19, qui démontre que la technique consistant à encapsuler la valeur retournée par une fonction dans un auto_ptr – ou un objet équivalent – est le seul moyen de vraiment s’assurer que cette fonction se comportera correctement en présence d’exceptions.
2. Lorsqu’elle est appelée, la fonction sink() prend le contrôle du pointeur qui lui est passé en paramètre car celui-ci est encapsulé dans un auto_ptr, ce qui assure la destruction de l’objet associé lorsque la fonction se termine (à moins que
sink() n’ait, au cours de son exécution, transmis le contrôle du pointeur à une autre fonction). On peut noter que, dans notre exemple, la fonction sink() est équivalente à pt.reset(0), dans la mesure où elle n’effectue aucune opération.
La suite du code montre un exemple d’utilisation de source() et sink() :
void f() {
auto_ptr<T> a( source() );
Instruction tout à fait correcte et sans danger : la fonction f() prend le contrôle de l’objet alloué par source(), l’auto_ptr assurant qu’il sera automatiquement détruit lors de la fin de l’exécution de f(), qu’il s’agisse d’une fin normale ou d’une fin
pré-maturée suite à une exception. C’est un exemple tout à fait classique de l’utilisation d’auto_ptr comme valeur de retour d’une fonction.
sink( source() );
Là encore, instruction correcte et sans danger. Étant donné l’implémentation mini-male de source() et sink(), ce code est équivalent à « delete new T(1) ». S’il est vrai que l’avantage procuré par auto_ptr n’est pas flagrant dans notre exemple, soyez convaincus que lorsque source()et sink() sont des fonctions complexes, l’utilisation d’un pointeur intelligent présente alors un intérêt certain.
sink( auto_ptr<T>( new T(1) ) );
Toujours correct et sans danger. Une nouvelle manière d’écrire « delete new T(1) » mais, encore une fois, une technique intéressante lorsque sink() est une fonc-tion complexe qui prend le contrôle de l’objet alloué.
Nous avons présenté ici les emplois classiques d’auto_ptr. Attention ! Méfiez-vous des utilisations qui différent de celles exposées plus haut : auto_ptr n’est pas un objet comme les autres ! Certains emplois non contrôlés peuvent causer des problè-mes, en particulier :
La copie d’un auto_ptr ne réalise pas de copie de l’objet pointé.
Ceci a pour conséquence qu’il est dangereux d’utiliser des auto_ptr dans un pro-gramme effectuant des copies en supposant implicitement – ce qui est généralement le cas – que les opérations de copie effectuent un clonage de l’objet copié.
Considérez par exemple le code suivant, régulièrement rencontré dans les groupes de discussions C++ sur l’Internet :
vector< auto_ptr<T> > v;
Cette instruction est incorrecte et présente des dangers ! D’une manière générale, il est toujours dangereux d’utiliser des auto_ptrs avec des conteneurs standards. Certains vous diront qu’avec leur compilateur et leur version de la bibliothèque standard, ce code fonc-tionne correctement, d’autres soutiendront que l’instruction ci-dessous est précisément citée à titre d’exemple dans la documentation d’un compilateur populaire : tous ont tort ! Le fait qu’une opération de copie entre auto_ptrs transmette le contrôle de l’objet pointé à l’auto_ptr cible au lieu de réaliser une copie de cet objet rend très dangereux l’utilisation des auto_ptr avec les conteneurs standards ! Il suffit, par exemple, qu’une implantation de
vector() effectue une copie interne d’un des auto_ptr stocké pour que l’utilisateur vou-lant obtenir ultérieurement cet auto_ptr récupère un objet contenant un pointeur nul.
Ce n’est pas tout, il y a pire :
v.push_back( auto_ptr<T>( new T(3) ) );
v.push_back( auto_ptr<T>( new T(4) ) );
v.push_back( auto_ptr<T>( new T(1) ) );
v.push_back( a );
(Notez ici que le fait de la passer par valeur a pour effet d’ôter à la variable a le contrôle de l’objet vers lequel elle pointe. Nous reviendrons sur ce point ultérieurement.)
v.push_back( auto_ptr<T>( new T(2) ) );
sort( v.begin(), v.end() );
Ce code est incorrect et dangereux. La fonction sort()ainsi d’ailleurs que l’ensemble des fonctions de la bibliothèque standard qui effectuent des copies fait l’hypothèse que ces copies laissent inchangé l’objet source de la copie. S’il y a plu-sieurs implémentations possible de sort(), l’une des plus courantes a recours, en interne, à un élément « pivot » destiné à contenir des copies des certains des objets à trier. Voyons ce qui se passe lorsqu’on trie des auto_ptrs : lorsqu’un élement est copié dans l’élément pivot, le contrôle de l’objet pointé par cet auto_ptr est transmis à l’auto_ptr pivot, qui est malheureusement temporaire. Lorsque le tri sera terminé, le pivot sera détruit et c’est là que se posera le problème : un des objets de la séquence originale sera détruit !
C’est pour éviter ce genre de problèmes que le comité de normalisation C++ a décidé de procéder à des modifications de dernière minute : l’auto_ptr a été spécifi-quement conçu pour provoquer une erreur de compilation lorsqu’il est utilisé avec un conteneur standard – règle qui a été mise en place, en pratique, dans la grande majo-rité des implémentations de la bibliothèque standard. Pour cela, le comité a spécifié que les fonctions insert() de chaque conteneur standard devaient prendre en para-mètre des références constantes, interdisant par là même leur emploi avec les
auto_ptr, pour lesquels le constructeur de copie et l’opérateur d’affectation prennent en paramètres des références non constantes.