Discussion :

[Kromagg]

Bonjour

Je travaille sur un petit moteur de rendu, très simple, et je me demandais dans quelles situations utiliser les pointeurs brut plutôt que les pointeurs intelligent et inversement. Pour le moment j'utilise les pointeurs bruts en paramètre de fonction et en retour de fonction, et les pointeurs intelligent en interne dans les classes (renderer, resource manager...)

Avez-vous des suggestions ?

[Médinoc]

Utiliser des pointeurs intelligents avec sémantique de transfert (unique_ptr<>) en retour de fonctions qui allouent un objet. Cela permet d'en assurer la libération.

[Luc Hermitte]

Un bon résumé des cas d'utilisation de chacun: http://exceptionsafecode.com/slides/...shared_ptr.pdf

[moldavi]

Bonjour.

Personnellement je n'utilise plus les pointeurs intelligents. On peut largement s'en passer pour de petits programmes. Pour des usines à gaz pourquoi pas.

Il y a quelques techniques simples pour gérer les pointeurs bruts, même en environnement multithreadé. Pour les connaître, il suffit de jeter un oeil sur mon projet open source (cf signature).

Je préfère un pointeur brut qui me pète à la tronche pendant le débugage, plutôt qu'un pointeur intelligent qui me dit que tout va bien, je gère. C'est une perte de temps en moins. Et je peux t'assurer que mon problème principal à l'heure actuelle, ce n'est pas les pointeurs.

Les pointeurs intelligents vont peut-être libérés la mémoire, mais ils n'indiqueront pas toujours les erreurs de programmation. Ils peuvent même les masquer. De quoi s'arracher les cheveux.

J'ai fait mon choix : plus de pointeurs intelligents dans mes programmes. J'écris un petit peu plus de code (pas énorme), mais au moins je gère le déroulé de mon code avec précision.

[Luc Hermitte]

Il faudra m'expliquer en quoi unique_ptr (/auto_ptr en 98/03) sont une perte de temps.
Et côté erreur de programmation, c'est tout le contraire de ce que ton post suggère : ils indiquent clairement dans la signature des fonctions les responsabilités des appelants et appelés. Et mieux que ça, cela ne nous laisse pas le choix dans le code. C'est le même principe que les références qui indiquent qu'il n'y a pas à tester la non-nullité ou les constructeurs qui disent "si l'objet existe c'est qu'il est dans un état pertinent et utilisable".

[Luc Hermitte]

@jblecanard j'ai vu passer ton message mais tu l'as supprimé ^^
Je commence à abonder dans le même sens que toi au sujet des shared_ptr<>. C'est suite à la remarque de Sean Parent (comme quoi un shared_ptr<> n'est pas mieux qu'une globale) que je remarque que ma tendance passée à employer unique_ptr/auto_ptr était bonne et pas assez intensifiée. Et comme toi, je n'ai que très peu de ressources véritablement partagées (car aucun propriétaire ne peut être établi). C'est en bonne partie pour cela que j'ai donné un lien vers un pdf qui selon les cas d'utilisation propose un type qui sera plus adapté que les autres.

C'est sûr que shared_ptr<T*> ou T* paraissent plus simples à employer : on pose le cerveau là où on écrit ces types. Seulement, on doit deux fois plus gamberger au moment d'employer les choses qui les manipulent. Avec la gamme complète de types à notre disposition (ptr_vector<>, unique_ptr<>, références, et même T* et shared_ptr<>) on passe certes du temps à réfléchir à ce que l'on fait au début, mais à l'utilisation, on n'a plus à réfléchir. Le code devient statiquement blindé : les contrats (au sens PpC, oui) sont établis et ne peuvent pas être contournés sans le faire exprès.

Donc tout ça pour dire que oui, j'ai bondi en lisant que les pointeurs intelligents c'est le mal. Sauf que c'est mettre dans un même sac toute la gamme d'outils à notre disposition. Après qui sait, aujourd'hui j'attaque sans pudeur les singletons car se sont des globales, peut-être que dans quelques années je ferai la même chose avec les pointeurs intelligents à comptage de référence. En attendant aujourd'hui, je préfèrerai voir ce genre de types utilisés autour de moi (à commencer par les libs tierces) plutôt que de devoir appeler des fonctions de libération à la main.