Discussion :

[hibou107]

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?

[oodini]

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...

[skeud]

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)

[oodini]

Euh perso je prefere eviter de les utiliser, j'aime bien gerer mes pointeur comme je l'entends

Tu n'aurais pas commencé la prog par le C, par hasard ?

et ça me permet de pouvoir les trimballer d'une classe a une autre

Il y a les shared_ptr, pour ça.

Edit: Lorsqu'une exception est lever, il est normal d'avoir des fuite de mémoire (qui dit exception dit fermeture du programme donc libération de la mémoire)

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).

[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.

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 ^^

[oodini]

Je vois pas trop l'interêt d'appeler le constructeur lors d'une exception

Effectivement, il n'y en a aucun. Je voulais écrire "destructeur" (corrigé).

imaginons que sa soit une exception qui interfère avec la stack, tu risquerais de faire plus de dégâts en continuant un bout de ton code

Je ne vois pas trop à quoi tu penses...

qu'en exitant de manière pure et dur ^^

De toute façon, quand j'excite, toute notion de pureté est assez lointaine.

[pyros]

qui dit exception dit fermeture du programme

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.

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.

[skeud]

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? )

[oodini]

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.

[skeud]

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

[oodini]

ou alors tu t'arrange pour etre sur qu'aucune exception ne soit lever en verifiant tes donnees etc,

Ç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.
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".

perso je trouve sa pas top de catcher les exception importante qui devraient interrompre le programme.

Un programme ne devrait JAMAIS être interrompu. Tu dois être le seul utilisateur de tes programmes pour tenir un tel discours.

[screetch]

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.

[skeud]

Ç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.
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".

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

[JolyLoic]

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.

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.

Par contre, des shared_ptr/weak_ptr/unique_ptr... oui, très souvent.

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)

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.

je n'aime pas trop les smart pointeurs (ils pètent l'auto complétion de visual ^^).

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).

[oodini]

auto_ptr, jamais, sa sémantique est par trop étrange.

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.

[pyros]

Qelle version ? Il ont pas mal refait l'intellisense en 2010, et l'auto complétion sur les shared_ptr marche très bien

Ah, bonne nouvelle 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.

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

[Goten]

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.

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.
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)

[skeud]

Je ne sais pas pour hibou, mais moi sa me parait encor moins clair qu'avant

[Flob90]

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.

[white_tentacle]

A noter que auto_ptr est déprécié, unique_ptr le remplace avantageusement comme l'ont dit Loic et Goten.

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 ?