Version imprimable
Bonjour,
Est ce que les développeurs expérimentés ici peuvent me dire si vous utilisez automatiquement les auto_ptr ou les smart pointer pour tous les pointeurs membres de l'objet.
Je travaille dans un cas simple qui consiste à instancier l'objet membre et le supprime à la fin, les objets membres ne sont utilisés que par l'objet principal.
C'est juste question d'habitude, est ce que vous évitez les new et delete systématiqument?
Si la méthode qui a créé l'objet lève une exception avant d'avoir appelé le delete, tu te retrouves avec une fuite de mémoire.
Si tu as utilisé new/delete plutôt qu'auto_ptr.
Si tu es certain que ton code n'est nullement susceptible de lever une exception, tu peux éventuellement te passer d'un auto_ptr...
Euh perso je prefere eviter de les utiliser, j'aime bien gerer mes pointeur comme je l'entends et sa me permet de pouvoir les trinballer d'une classe a une autre, on sait jamais comment le code va evoluer au fur et a mesure du developpement.
Edit: Lorsqu'une exception est lever, il est normal d'avoir des fuite de memoire (qui dit exception dit fermeture du programme donc liberation de la memoire)
Tu n'aurais pas commencé la prog par le C, par hasard ? ;)Citation:
Envoyé par skeud
Il y a les shared_ptr, pour ça.Citation:
Envoyé par skeud
C'est normal quand tu utilises new/delete. Avec les smart pointers, tu es assuré que les objets construits par l'instance courante sont "dépilés", et donc que leurs destructeurs sont appelés (ce qui n'est pas le cas de l'objet qui lève l'exception).Citation:
Envoyé par skeud
Si justement j'ai commencer par le C, mais bon je me retrouve presque jamais a faire des new en c++ avec tout les super outils de ce langage. :mouarf:
Je vois pas trop l'interet d'appeler le constructeur lors d'une exception, imaginons que sa soit une exception qui interfere avec la stack, tu risquerais de faire plus de degats en continuant un bout de ton code qu'en exitant de maniere pure et dur ^^
Effectivement, il n'y en a aucun. Je voulais écrire "destructeur" (corrigé). :roll:Citation:
Envoyé par skeud
Je ne vois pas trop à quoi tu penses...Citation:
Envoyé par skeud
De toute façon, quand j'excite, toute notion de pureté est assez lointaine. ;)Citation:
Envoyé par skeud
Ben non, l'intérêt d'une exception est justement de pouvoir la gérer plus haut et d'éviter de quitter le programme.Citation:
qui dit exception dit fermeture du programme
Et les smart pointer permettent, entre autre, d'éviter les fuites mémoire lorsqu'une exception remonte la pile.
Perso, bien que je n'aime pas trop les smart pointeurs (ils pètent l'auto complétion de visual ^^), je les conseils vivement.
ah ok, dans ma logique exception->grosse erreur->arret du programme ^^
Mais bon ensuite sa depend de l'utilisation des exception, trop formater a utiliser les retour en cascade (qui as dit comme en C? :mrgreen:)
Tu peux coder en prenant en compte les mécanismes d'exceptions (ce qui justifie l'utilisation des smart pointers), tout en utilisant les retours en cascade quand tu le peux. Moi, j'évite de créer mes propres types d'exception, car l'utilisation des exceptions est coûteuse.
Mais c'est le système qui t'en balance une, tu es bien content de pouvoir les chopper, et de d'assurer que cela n'occassionnera pas une fuite mémoire.
ou alors tu t'arrange pour etre sur qu'aucune exception ne soit lever ;) en verifiant tes donnees etc, perso je trouve sa pas top de catcher les exception importante qui devraient interompre le programme.
Sa serait un peu similaire a intercepter un SIGSEV :mouarf:
Ça, c'est le discours de mon ancien chef. Sauf que quand j'ai quitté la boîte, son code créait toujours des fuites de mémoire.Citation:
Envoyé par skeud
Comme toi, il restait sur ses réflexes de codeur en C.
Sauf qu'on sait tous que même les meilleurs codeurs ne peuvent se prémunir des fuites de mémoire. C'est en partie ce qui a motivé la création de Java et C#.
C'est comme dire "Avoir une ceinture de sécurité, ça ne sert à rien; il suffit de bien conduire".
Un programme ne devrait JAMAIS être interrompu. Tu dois être le seul utilisateur de tes programmes pour tenir un tel discours.Citation:
Envoyé par skeud
ca évite aussi les leaks mémoire par inadvertance (new et pis on oublie le delete)
sur mon projet il n'y a plus beaucoup de pointeurs nus, juste des smart pointeurs (refptr, weakptr et scopedptr, qui sont très peu différent de ceux du standard)
j'ai pas vu un leak mémoire depuis 2 ans, et du coup j'ai activé la detection de leak a la fermeture du programme sous windows, et elle est toujours vide. Et j'ai pas vu une "access violation" depuis 3 ans sur ce projet qui était du a un objet mort auquel on essaye d'accéder.
comme j'ai dis plus haut j'utilise tres peu de new et delete, donc pas besoin de gerer la memoire, mais c'est vrai que sa semble tres interressant ces ptits bijoux, je pense que j'y reflechirais a deux fois la prochaine fois que l'occasion se presente ;)Citation:
Envoyé par oodini
auto_ptr, jamais, sa sémantique est par trop étrange. Éventuellement un auto_ptr const, par endroit, si je ne peux utiliser ni boost, ni C++11.Citation:
Envoyé par hibou107
Par contre, des shared_ptr/weak_ptr/unique_ptr... oui, très souvent.
C'est un mode de gestion des erreurs, qui ne marche pas forcément trop mal pour des programmes à la durée de vie limités (utilitaires en ligne de commande). Ça l'est beaucoup moins par exemple pour un serveur qui doit rester monté en mémoire en permanence. Et quand on fait une bibliothèque, on ne sait généralement pas quel modèle de gestion d'erreur le code client va appeler, donc on doit être prêt à gérer tout.Citation:
Envoyé par skeud
Qelle version ? Il ont pas mal refait l'intellisense en 2010, et l'auto complétion sur les shared_ptr marche très bien (et j'aime aussi beaucoup le soulignement des erreurs de syntaxe à la volée, sans même compiler).Citation:
Envoyé par pyros
Je te trouve trop dogmatique. Il faut l'utiliser en ayant conscience de son comportement, c'est tout, et dès que ce dernier impose une friction intellectuelle, passer au shared_ptr. Mais des fois, un auto_ptr suffit amplement.Citation:
Envoyé par JolyLoic
Ah, bonne nouvelle :ccool: Mais je trouve le 2010 un peu trop lourd, et j'ai pour habitude d'utiliser un visual de génération n-1 par rapport à ma machine, histoire de pas passer la matinée à le lancer.Citation:
Qelle version ? Il ont pas mal refait l'intellisense en 2010, et l'auto complétion sur les shared_ptr marche très bien
J'étais sur 2008 et on utilisait pas mal les boost smart pointer. C'est dingue à quel point on est perdu lorsqu'on a plus l'autocompletion :calim2:
Nah, shared_ptr et auto_ptr n'ont rien à voir. Si tu dois passer à quelque chose quand tu utilises un auto_ptr alors c'est un unique_ptr.Citation:
Envoyé par oodini
Et non, Loic à raison, c'est bien trop piégeux, donc un auto_ptr const ou un scoped_ptr (même résultat à l'exception de reset)
Je ne sais pas pour hibou, mais moi sa me parait encor moins clair qu'avant :aie:
A noter que auto_ptr est déprécié, unique_ptr le remplace avantageusement comme l'ont dit Loic et Goten.
@OP: Personnelement oui, les seul cas où j'utilise des pointeurs nues c'est quand ceux-ci n'ont pas vocation à avoir de responsabilité par rapport à l'objet qu'il pointe (ie quand il servent de référence sans que je puisse mettre une référence à cette endroit).
Il faut que tu distingues le degré de responsabilité de ton pointeur :
- Aucune, un poibnteur nue convient
- Strict sans transfert possible (ca me semble être le cas que tu présentes dans ton premier message) : scoped_ptr (c'est une simple capsule RAII)
- Strict avec transfert possible : unique_ptr
- Partagé : shared_ptr
Ensuite on peut encore distinguer plein de paramètres, comme le fait A.Alexandrescu dans Loki, au final on obtient des dizaines de pointeurs intelligents possible.
Quelqu’un peut-il m’expliquer la différence entre les deux ? Personnellement, j’utilise auto_ptr chaque fois que j’ai besoin de faire du transfert d’ownership (c’est à dire rarement), j’en suis satisfait. Qu’apporte unique_ptr de plus ou de moins ?Citation:
Envoyé par Flob90
D'un le support de la move semantic (c'est important) et l'interface est plus "logique" (comprendre safe), c'est à dire que la copie est interdite (c'est ce qui pété avec les auto_ptr).Citation:
Envoyé par white_tentacle
Néanmoins comme il supporte la move semantics et que tu veux transférer l'ownership tu peux toujours le faire via un move mais au moins maintenant c'est explicite.
unique_ptr : Le transfert de propriété respecte la move semantic :
- Automatiquement quand l'objet est un vrai temporaire
- Explicitement si on utilise std::move
- Jamais quand on copie un pointeur (d'ailleurs la copie est interdite)
auto_ptr : Le transfert de propriété a lieu quand on copie le pointeur. On a donc dans les mains une source qui ne contient plus rien, qu'on doit éviter d'utiliser.