Trimballer un unique_ptr avec la sémantique de mouvement

Citation:

---

Envoyé par koala01

J'utilisais le terme "surcharger" au sens propre du terme, et non au sens de surcharge du point de vue C++ (ne me fais pas croire que tu ne l'avais pas remarqué, tu descendrais dans mon estime :D ) ;)

---

<edit> Je viens de comprendre. <edit>

Citation:

---

Envoyé par koala01

Si je te montre un exemple de vingt lignes, tu me taxeras encore de je ne sais pas quoi.

Considère simplement le fait que, si la responsabilité du pointeur n'est pas prise dés le départ par "quelque chose", il est très facile d'arriver à un point où la responsabilité peut avoir été prise ... ou non, en fonction du trajet qu'aura suivi le pointeur et ce du seul fait des possibilités offertes par le langage (l'héritage avec la possibilité des comportements polymorphes, création de foncteurs, l'appel de fonction "en cascade", la surcharge des fonctions, la possibilité d'avoir des valeurs par défaut pour les arguments, j'en passe et de meilleur).

---

C'est justement ceci que je ne comprend pas ... Dans les quelques morceaux de code que j'ai montré avant et qui illustrent les règles que j'estime bonnes (ça reste un avis), je ne vois pas où je pourrais "perdre" une responsabilité ... Avec un code qui me le montre, je pourrais surement l'envisager un peu plus 8-) (et je ne crois pas t'avoir taxer de quoi que ce soit, j'ai juste l'impression qu'on a une incompréhension mutuelle, rien de plus :aie: ).

Je pense que c'était surchargé au sens français de "y'en a trop". (peut-être me trompè-je encore ?)

Citation:

---

Envoyé par Flob90

<edit> Je viens de comprendre. <edit>

---

Ah, tu me rassures :D

Citation:

---

C'est justement ceci que je ne comprend pas ... Dans les quelques morceaux de code que j'ai montré avant et qui illustrent les règles que j'estime bonnes (ça reste un avis), je ne vois pas où je pourrais "perdre" une responsabilité ... Avec un code qui me le montre, je pourrais surement l'envisager un peu plus 8-) (et je ne crois pas t'avoir taxer de quoi que ce soit, j'ai juste l'impression qu'on a une incompréhension mutuelle, rien de plus :aie: ).

---

Je vais être plus précis :

Je pourrais te montrer un tas de lignes de code dans lesquelles le fait qu'une classe particulière prend à un moment donné la responsabilité de la durée de vie d'un pointeur risque fort de mener à des catastrophes.

Une grande partie d'entre elles ne le ferait que de manière strictement indirecte --et encore, pas forcément, en fonction du type réel de l'objet (parce que c'est un comportement polymorphe) ou d'un argument particulier -- et nécessiterait de retracer chaque appel un à un pour arriver à s'en rendre compte.

Le problème de toutes ces lignes de code reste pourtant toujours le même : celui qui les écrit fait une connerie quelque part. Et je peux donc très certainement compter sur toi pour me répondre du "oui, mais si l'utilisateur fait n'importe quoi...". Et tu aurais tout à fait raison : l'utilisateur ferait, dans les cas que je te montrerais, du grand n'importe quoi.

Ce problème est, effectivement, beaucoup moins susceptible d'arriver si, dés le départ, tu bases ton développement et tes décisions sur le fait de définir clairement qui prend la responsabilité de détruire tes pointeurs et qui peut, le cas échéant, transférer cette responsabilité à qui, parce que tu seras, a priori, parti du principe que "quelque chose" prend déjà la responsabilité de la durée de vie du pointeur.

Je n'ai jamais dit que cette approche était mauvaise, et je ne le dirai jamais! Au contraire, je trouve cette approche particulièrement saine.

Mais le fait est que lorsque tu bases tout ton développement sur cette approche, lorsque toutes ces décisions sont basée sur cette approche, hé bien que tu as une approche globale du problème.

Moi, je réagissais essentiellement à la phrase de jean-luc -- sur laquelle je ne suis pas d'accord -- qui disait

Citation:

---

A nouveau tes arguments ressemblent furieusement à ceux que j'ai entendu il y a 15 ans contre std::string dans les interfaces.

---

Je faisais remarquer que tu pouvais n'avoir qu'une vision très limitée du projet en décidant de modifier une classe ou une fonction pour qu'elle manipule une std::string en interne au lieu de manipuler un char *.

Une telle modification n'aura qu'un impact très limité par rapport au projet : elle se limitera généralement à la fonction (ou la classe) que tu modifies et, dans le pire des cas, à quelques fonctions connexes.

Par contre, je faisais remarquer qu'une vision limitée à la seule classe (ou fonction) modifiée de manière à ce qu'elle manipule un pointeur intelligent (quel qu'il soit) au lieu d'un pointeur nu n'est simplement pas suffisante, que la modification n'impacterait pas seulement la classe ou la fonction modifiée et "quelques fonctions connexes" dans le pire des cas, mais qu'il y avait de grandes chances pour que toutes les classes et toutes fonctions qui manipulent le pointeur en question subissent un impact de manière direct ou indirect du à la modification que tu apporteras.

Il faut donc que tu aies une approche globale du problème et non une approche limitée à une seule fonction ou à une seule classe. Autrement, tu as de grandes chances de courir à la catastrophe.

Le code qui mènera à la catastrophe n'a pas beaucoup d'importance, car de toutes façons, il dénotera une erreur de la part de l'utilisateur.

Il peut aussi bien s'agir d'une valeur d'argument par défaut (oubliée de l'utilisateur) qui fait passer la fonction dans une branche de test plutôt qu'une autre, que d'un comportement polymorphe qui, manque de bol, appelle une fonction qu'il ne devrait pas, ou même d'un thread, oublié de tous, qui manipule un pointeur, cela n'a aucune espèce d'importance.

Ce qui est sur, c'est:

• qu'il n'y a strictement rien qui pourra te prémunir contre le problème (*)
• que si le problème se pose ( et si l'on en crois murphy, il se posera d'office un jour), le résultat sera toujours le même : une erreur de segmentation.

(*)Je te l'accorde, tu éviteras sans doute une bonne partie des problèmes en ayant, dés le départ, une approche qui consiste à utiliser des pointeurs intelligents.

Je t'accorde aussi que, si tu indiques clairement dans ta signature de fonction qu'elle attend spécifiquement un unique_ptr, ca évitera une partie des problèmes (tout en en posant d'autres au niveau de la résistance aux exceptions, ce que j'ai abordé par ailleurs ;))

Mais le fait est que cela n'empêchera nullement à une fonction1 d'appeler fonction2 qui appelle fonction3 (...) appelle fonctionN qui appelle la fonction qui transmet le pointeur sous la forme d'un pointeur intelligent et qu'il n'y a strictement rien qui puisse te prémunir contre le fait qu'un de ces fonctions risque de poser problème.
D'autant plus que, connaissant certains développeurs, il ne faudrait pas s'étonner outre mesure (c'est encore une connerie, bien sur, tout le monde en est conscient à part celui qui le fera :D ) s'ils suivent un raisonnement proche de

Citation:

---

merde, il me fait ch... à demander un unique_ptr!!!
je sais pas pourquoi, mais bon, s'il faut faire plaisir au compilateur, allez

Code:

---

1 2 3 4 5 6 7 8

void foo(Type * ptr){ /* y font ch... avec leurs unique_ptr!!! */ bar(std::unique_ptr<Type>(ptr)); /* j'espère qu'ils seront content comme ca, maintenant, je continue à   * travailler sur mon pointeur   */ ptr->behaviour(); // note de koala : oupps!!! }

---

---

Ce n'est pas flatteur pour les développeurs, mais tu sais aussi bien que moi que cela pourrait très facilement arriver ;)

Citation:

---

Envoyé par koala01

Et ca, ben l'utilisateur le saura en fonctions des comportements que l'objet expose :

• S'il rencontre une fonction get() ou similaire, l'objet est d'accord pour prêter le pointeur en en gardant la responsabilité
• S'il rencontre une fonction release() ou similaire, l'objet est d'accord de se défaire de la responsabilité.

Il n'y a, à mon sens, pas besoin d'exposer d'avantage les choses que cela.

---

Nous on dit que les comportements que l'objet expose sont prendre un unique_ptr ou en retourner un. Ce qui nous permet de savoir sans ambiguïté ce qu'est une fonction similaire a get ou release et d'utiliser des noms clairs plutôt que convenant a une classe technique.

Citation:

---

Envoyé par koala01

En C++03, très certainement, parce qu'on leur surine à longueur de journée que "à chaque new doit correspondre un delete".

---

J'ai exactement les mêmes problèmes que Loïc avec cette formulation, je ne vais pas la défendre. (Un problème que Loïc n'a pas cité, c'est que plus d'une fois j'ai du expliquer que non, le delete n'avait pas a se retrouver dans la même fonction, c'est même relativement rarement le cas car il y a de meilleures alternatives quand ce serait adéquat).

Citation:

---

J'espère sincèrement qu'avec C++11, la règle que l'on surinera aux gens deviendra

---

La règle à laquelle on tendait depuis auto_ptr et que C++11 permet enfin d'appliquer sans impacts sur les perfs, c'est "new et delete c'est a reserver pour l’implémentation de pointeurs intelligents et des allocateurs, quand on veut allouer un objet, on utilise le make_XXX du smart pointeur implementant la politique qui va gérer sa durée de vie". Ça ne m’étonnerait pas beaucoup qu'il devienne plus courant de définir des opérateurs new et delete dans une classe que d'y faire un appel direct.

Citation:

---

Envoyé par koala01

D'autant plus que, connaissant certains développeurs, il ne faudrait pas s'étonner outre mesure (c'est encore une connerie, bien sur, tout le monde en est conscient à part celui qui le fera :D ) s'ils suivent un raisonnement proche de

---

L'alternative que tu sembles préconiser étant

Code:

---

1 2 3 4 5 6 7 8 9 10

void foo(Type * ptr){ bar(ptr); ptr->behaviour(); // Et quand on trouve enfin le problème: // Oh les cons, on dirait du C++ de grand papa, sont même pas foutu // d'utiliser un équivalent à eux d'unique_ptr<> (ce qui voudrait dire qu'ils // sont atteints de NIHite aiguë, mais c'est préférable à ce code pourri) // pour indiquer qu'ils prennent le contrôle du pointeur. }

---

je ne vois pas en quoi elle est préférable. Je le vois tellement peu que j'en viens à me demander si tu trolles; dans ce cas, STP, dis le moi, que j’arrête de perdre mon temps.

Citation:

---

Envoyé par koala01

Mais est-ce que cela doit forcément passer par le fait d'utiliser unique_ptr dans la signature de la fonction :question:

A mon sens, non : unique_ptr n'est que le détail d'implémentation qui permet à la classe ou à la fonction d'assumer la responsabilité, rien d'autre.

---

Et dans ce cas, que proposes tu d'utiliser dans l'argument de la fonction pour indiquer le transfert de propriété de l'objet pointé de telle manière que ce transfert soit :
- Non ambigu
- Dans le code et non dans les commentaires
- Compréhensible par n’importe quel développeur C++ raisonnablement formé

Citation:

---

Envoyé par koala01

Je faisais remarquer que tu pouvais n'avoir qu'une vision très limitée du projet en décidant de modifier une classe ou une fonction pour qu'elle manipule une std::string en interne au lieu de manipuler un char *.

Une telle modification n'aura qu'un impact très limité par rapport au projet : elle se limitera généralement à la fonction (ou la classe) que tu modifies et, dans le pire des cas, à quelques fonctions connexes.

---

D'après mon expérience, une telle modification n'est justement pas anodine. En remplaçant des char* par des strings, on oublie des cas où une sous fonction cachée modifiait la chaîne initiale, et où maintenant elle va modifier une copie... Passer d'une sémentique de référence à une sémentique de valeur n'est pas anodin...

Citation:

---

Envoyé par koala01

Par contre, je faisais remarquer qu'une vision limitée à la seule classe (ou fonction) modifiée de manière à ce qu'elle manipule un pointeur intelligent (quel qu'il soit) au lieu d'un pointeur nu n'est simplement pas suffisante, que la modification n'impacterait pas seulement la classe ou la fonction modifiée et "quelques fonctions connexes" dans le pire des cas, mais qu'il y avait de grandes chances pour que toutes les classes et toutes fonctions qui manipulent le pointeur en question subissent un impact de manière direct ou indirect du à la modification que tu apporteras.

Il faut donc que tu aies une approche globale du problème et non une approche limitée à une seule fonction ou à une seule classe. Autrement, tu as de grandes chances de courir à la catastrophe.

---

J'ai l'impression que tu te places dans un contexte "modifications minimales d'un code existant", et non pas dans le contexte "qu'est-ce qui est mieux pour du code, dans l'absolu". Ce qui rend la discussion plus difficile. Mais même dans le contexte en question, si les responsabilités du code initiale sont bien gérées et explicitées, passer des unique_ptr ne devrait pas causer de problèmes. Si elles ne le sont pas, le refactoring à effectuer et clairement plus complexe.

Citation:

---

Envoyé par yan

Moi, je comprend que tu aimerais un unique_ptr qui pourrais se transformer en weak_ptr dés que quelqu'un prend possession.

Et c'est pourquoi tu parle de Qt. Avec addWidget tu donne la gestion de vie à quelqu'un mais tu veux toujours pouvoir y accéder:
1- Ce qui n'est pas possible avec un unique_ptr.
2- un shared ne va pas car un widget ne peux pas être enfant de 2 widgets.

---

Je ne comprends pas pourquoi tu dis ça. Le fait de transférer la responsabilité n’invalide pas le pointeur sous-jacent, uniquement l’unique_ptr (pour se prémunir d’erreurs). Et ça va dans le sens de ce que disait Loïc à propos du besoin d’un smart pointer « observateur ».

Je peux écrire

Code:

---

1 2 3 4 5 6 7 8

int f(A& object) { std::unique_ptr<B> b = std::make_unique("toto"); std::observer_ptr<B> b_obs = b.get(); // Pour l’instant, B*… object.addWigdet(std::move(b)); /// b n’est plus utisable. En revanche, b_obs est toujours valide tant que A garde la ressource }

---

Et d’ailleurs, j’aurais tendance à plutôt écrire cet idiome sous la forme :

Code:

---

1 2 3 4 5

std::observer_ptr<B> b = object.addWidget(std::make_unique("toto")); if(b) { // traitement }

---

qui : :
- est plus explicite sur le fait que la responsabilité de l’objet est transférée, mais l’objet n’est pas détruit immédiatement puisqu’on renvoie une référence dessus
- est plus courte à écrire

Citation:

---

Envoyé par white_tentacle

Je ne comprends pas pourquoi tu dis ça. Le fait de transférer la responsabilité n’invalide pas le pointeur sous-jacent, uniquement l’unique_ptr (pour se prémunir d’erreurs).

---

Je ne voulais pas dire que le pointeur est invalidé mais que l'unique_ptr deviens null et que donc on n'y as plus accès ^^.

Un smartpointer "observateur" serait une solution intéressante.

Le seul observateur intelligent pour un unique_ptr<T> c'est une simple référence T&. Vous aurez du mal à trouver mieux que ça et de toute façon c'est bien suffisant pour aller avec unique_ptr (et n'allez pas me dire que c'est compliqué à utiliser :aie:). Si on cherche quelque chose de plus évolué, il faudra de toute façon une structure de pointeur intelligent plus complexe que unique_ptr qui ne peut pas offrir plus que ce qu'il a actuellement.

Citation:

---

Envoyé par germinolegrand

Le seul observateur intelligent pour un unique_ptr<T> c'est une simple référence T&. Vous aurez du mal à trouver mieux que ça et de toute façon c'est bien suffisant pour aller avec unique_ptr (et n'allez pas me dire que c'est compliqué à utiliser :aie:).

---

Si je pouvais mettre un T& dans un vector, je serais d'accord avec toi...

Citation:

---

Envoyé par yan

Je ne voulais pas dire que le pointeur est invalidé mais que l'unique_ptr deviens null et que donc on n'y as plus accès ^^.

Un smartpointer "observateur" serait une solution intéressante.

---

Presqu'à chaque fois que je me dis qu'un weak_pointer pour unique_ptr serait utile, au final je me rend compte que j'ai besoin d'observer plus que la destruction de l'objet ou que je dois faire plus que remettre le pointeur à nullptr lors de celle-ci. Je dois donc implémenter un mécanisme plus général d'observation de l'objet qui sert naturellement pour la destruction. C'est moins vrai pour les shared_ptr, je me demande s'il y a une raison profonde, si c'est stylistique chez moi, si c'est un biais de confirmation ou si c'est simplement du hasard.

Citation:

---

Envoyé par JolyLoic

Si je pouvais mettre un T& dans un vector, je serais d'accord avec toi...

---

Mmh, je viens de remarquer std::reference_wrapper qui remplit justement cette fonction si j'en crois sa documentation.
Toutefois ma remarque s'applique principalement aux interfaces, même lorsque je stocke des pointeurs nus pour me tenir lieu de référence, je prends tout de même des références en arguments de mes fonctions.

@Jean-Marc : le problème c'est que pour faire un observateur capable d'observer ne serait-ce que la destruction d'un unique_ptr, cela nécessite un compteur de références partagées, c'est d'ailleurs la raison pour laquelle je considère le design de weak_ptr une ignominie car horriblement intrusif et inextensible (en effet, même si vous n'en avez pas besoin, vous payez de la ram et du CPU pour, ce qui est bien contraire à la philosophie habituelle du C++ !).

Pas forcément un compteur: Juste une liste chaînée de listeners, invoqués lors de la destruction, pourrait suffire.

Et si on ne supporte pas la suppression de listener en temps constant, on n'a même pas besoin de doubler le chaînage!

Code:

---

1 2 3 4 5 6 7 8

void foo(Type * ptr){ /* y font ch... avec leurs unique_ptr!!! */ bar(std::unique_ptr<Type>(ptr)); /* j'espère qu'ils seront content comme ca, maintenant, je continue à   * travailler sur mon pointeur   */ ptr->behaviour(); // note de koala : oupps!!! }

---

pourquoi ça ne met pas à nul ptr après la construction de l'unique_ptr ? ils sont vicieux les mecs qui développent C++ !