"unique_ptr" comment en profiter?

Version imprimable

30/07/2009, 12h33
_skip

"unique_ptr" comment en profiter?

Bonjour,

En cherchant une façon sûre (et si possible relativement efficace) de retourner depuis une fonction des objets ayant été alloué dynamiquement, je suis tombé sur des exemples de code utilisant des unique_ptr qui semblent justement offrir la possibilité de transférer l' "ownership" d'un objet.

J'ai trouvé l'implémentation suivante sans trop savoir si elle est encore d'actu :
http://home.roadrunner.com/~hinnant/unique_ptr03.html

Ou sinon dans la librairie boost que j'utilise déjà
boost/interprocess/smart_ptr/unique_ptr.hpp
Mais ce dernier à l'air un peu différent, déjà parce que son template avale 2 arguments de type, et aussi parce que ce namespace nommé "interprocess" m'inquiète un peu. Je suis pas sûr que ça correspond à ce que je cherche en réalité.

Surtout qu'il n'en est pas fait mention dans http://www.boost.org/doc/libs/1_39_0.../smart_ptr.htm

D'ou question, comment est-ce que j'aurai intérêt à faire pour profiter de ces unique_ptr de façon sûre?

Bonjour,
Oui, unique_ptr est en effet un excellent pointeur intelligent, très léger, qui permettra de résoudre élégamment certains problèmes.

Cependant unique_ptr fait partie de la nouvelle norme C++0x et nécessite le support de la sémantique de déplacement et des rvalue references. Il n'est donc disponible que sur les compilateurs extremement récents (gcc 4.4 et Visual Studio 2010 beta).

Dans boost il y a des efforts en ce moment pour construire une bibliothèque Boost.Move qui émulerait proprement la sémantique de déplacement pour le C++ actuel, mais ce n'est pas encore fini. Il ya des morceaux à droite à gauche, comme par exemple dans la bibliothèque Boost.interprocess où l'auteur a developpé un unique_ptr en se basant sur l'implémentation de Hinnant.

Donc au final, c'est encore un peu brut de décoffrage tout ça. Je pense qu'il est plus prudent, à l'heure actuelle d'utiliser des shared_ptr. Ils sont directement disponibles dans la STL sur les compilateurs très récents (dans le header <memory>) mais ils sont aussi présents dans boost depuis des années, donc parfaitement stables, optimisés et débuggés. C'est une solution éprouvée et tu trouveras surement beaucoup plus d'aide, d'info et de tutorial sur le net qu'avec les unique_ptr. :lol:

Bien sur, les shared_ptr ne permettent pas vraiment de transférer "l'ownership" (... comment ça se traduit en français !? :koi:), seulement de la partager.

Dans certains cas, ça revient au même :
Code:

1 2 3 4 5 6 7 8 9 10 shared_ptr<Truc> make_truc(arguments....) { // création du shared_ptr. Le compteur de référence passe à 1. shared_ptr<Truc> ptr(new Truc(arguments...)); return ptr; } shared_ptr<Truc> t = make_truc(); // copie du shared_ptr, le compteur passe à 2 //"destruction" du shared_ptr local à make_truc, le compteur repasse à 1.
Comment comptais-tu utiliser les unique_ptr ? Il doit y avoir moyen de faire la même chose (un peu moins efficacement) avec des shared_ptr.

30/07/2009, 13h47
ram-0000

Citation:

Envoyé par Arzar

Bien sur, les shared_ptr ne permettent pas vraiment de transférer "l'ownership" (... comment ça se traduit en français !? :koi:), seulement de la partager.

L'appropriation ? le fait que l'objet pointeur soit propriétaire de l'objet pointé.
30/07/2009, 15h31
_skip

Citation:

Oui, unique_ptr est en effet un excellent pointeur intelligent, très léger, qui permettra de résoudre élégamment certains problèmes.

Cependant unique_ptr fait partie de la nouvelle norme C++0x et nécessite le support de la sémantique de déplacement et des rvalue references. Il n'est donc disponible que sur les compilateurs extremement récents (gcc 4.4 et Visual Studio 2010 beta).

Il me semblait en effet que c'était partie intégrante d'une nouvelle spécification... Les documents trouvés à ce sujet datent tout de même d'il y a des lustres donc j'ai pensé que c'était éventuellement mes outils ici qui était trop vieux ou un souci de configuration.

Citation:

Dans boost il y a des efforts en ce moment pour construire une bibliothèque Boost.Move qui émulerait proprement la sémantique de déplacement pour le C++ actuel, mais ce n'est pas encore fini. Il ya des morceaux à droite à gauche, comme par exemple dans la bibliothèque Boost.interprocess où l'auteur a developpé un unique_ptr en se basant sur l'implémentation de Hinnant.

Je suis tombé dessus en effet, j'ai pas osé utiliser...

Citation:

Donc au final, c'est encore un peu brut de décoffrage tout ça. Je pense qu'il est plus prudent, à l'heure actuelle d'utiliser des shared_ptr. Ils sont directement disponibles dans la STL sur les compilateurs très récents (dans le header <memory>) mais ils sont aussi présents dans boost depuis des années, donc parfaitement stables, optimisés et débuggés. C'est une solution éprouvée et tu trouveras surement beaucoup plus d'aide, d'info et de tutorial sur le net qu'avec les unique_ptr.

Oui j'ai commencé à les utiliser cet après-midi justement.

Citation:

Comment comptais-tu utiliser les unique_ptr ? Il doit y avoir moyen de faire la même chose (un peu moins efficacement) avec des shared_ptr.

Exactement ce qu'il y a dans ton exemple, c'est à dire retourner un objet que j'ai fabriqué dans une méthode. En l'occurence c'est un std::vector, j'aurai aussi pu demander au code client de me passer le vector en paramètre par référence, mais je dispose de beaucoup plus d'informations pour l'allouer à la bonne taille dès le départ.

Merci en tout cas pour la réponse bien complète.