Discussion :

[Pyramidev]

auto_ptr<> (déprécié en C++11, supprimé en C++14)

auto_ptr existe toujours en C++14. C'est en C++17 qu'il est supprimé.
http://en.cppreference.com/w/cpp/memory/auto_ptr

[Oscar.STEFANINI]

Visiblement les pointeurs intelligents ont pas mal changés dans les dernières normes. Quand on démarre le C++, comme moi, c'est pas forcément évident. Je sais que Koala01 à écris un livre en 2014, peut-être est-ce qu'il traite des pointeurs intelligents ? Enfin visiblement ça semble être un sujet tout à fais à la mode, peut etre un article sur les pointeurs intelligents serait valorisant sur developpez ? ^^

[JolyLoic]

Il y a mon article : http://loic-joly.developpez.com/tuto...mart-pointers/
Il est un peu vieux, mais je crois qu'il reste d'actualité.
Si je devais le réécrire aujourd'hui, j'insisterais probablement plus détaillé unique_ptr, et j'aurais plus précisé comment passer des arguments à une fonction.

[Oscar.STEFANINI]

Merci beaucoup

[Luc Hermitte]

On insiste (dans les communautés en-ligne) sur les pointeurs intelligents et sur l'importance du RAII depuis longtemps.

Ils ne sont pas plus compliqué que la gestion manuelle qui est impossible à faire correctement.

[koala01]

Visiblement les pointeurs intelligents ont pas mal changés dans les dernières normes. Quand on démarre le C++, comme moi, c'est pas forcément évident. Je sais que Koala01 à écris un livre en 2014, peut-être est-ce qu'il traite des pointeurs intelligents ? Enfin visiblement ça semble être un sujet tout à fais à la mode, peut etre un article sur les pointeurs intelligents serait valorisant sur developpez ? ^^

A vrai dire, mon livre est d'avantage orienté sur les bonnes pratiques et le respect des principes de base (tels que SOLID), mais il parle néanmoins des pointeurs intelligents et de leur intérêt.

Car il n'y a pas de miracle: la gestion manuelle de la mémoire est une véritable plaie en C++, et on ne se gène pas pour le rappeler déjà depuis bien longtemps à chaque fois que l'occasion se présente.

C'est la raison pour laquelle on insiste depuis plus de dix ans maintenat sur l'impérative nécessité d'utiliser les collections diverses proposées par la bibliothèque standard au lieu de se laisser aller au NIH en essayant de les implémenter par soi même.

Mais elles ne résolvent pas tous les problèmes, car il reste malgré tout des cas où l'allocation dynamique manuelle de la mémoire est obligatoire. Les pointeurs intelligents sont justement prévus pour sécuriser ces cas bien particuliers pour lesquels il reste (restait) cohérent de faire explicitement appel à new en nous permettant de garantir que la mémoire allouée sera libérée exactement au bon moment

D'une certaine manière, je rêve d'arriver à faire prendre conscience au gens que, à l'heure actuelle, ne pas utiliser les pointeurs intelligents est aussi aberrant que d'essayer de cuisiner sans jamais avoir recour au sel

[Luc Hermitte]

Ah. Je cuisine généralement sans rajouter de sel. Par contre les pointeurs intelligents... je m'en sers.

[zobal]

D'une certaine manière, je rêve d'arriver à faire prendre conscience au gens que, à l'heure actuelle, ne pas utiliser les pointeurs intelligents est aussi aberrant que d'essayer de cuisiner sans jamais avoir recour au sel

On dirait du Jean-Claude Van Damme, en plus condescendant.

[koala01]

On dirait du Jean-Claude Van Damme, en plus condescendant.

Tu n'as sans doute pas encore lu énormément de mes interventions, sinon tu saurais que j'aime utiliser des phrases choc pour faire réagir ceux qui me lisent, que j'essaye malgré tout toujours de ne pas trop heurter leur sensibilité (ou de leur faire des excuses sincères lorsque c'est le cas), mais que, à la réflexion, mes remarques sont généralement des plus sensées et dignes d'être suivies (même s'il m'arrive aussi de dire d'énormes conneries )

[wolinn]

J'utilise des pointeurs intelligents lorsque celà présente vraiment un intérêt sans inconvénients, mais dans un noyau de calcul intensif, il n'y a que des pointeurs stupides, on ne veut pas d'un niveau d'indirection supplémentaire, de code caché et tests divers qui brisent inutilement le flot d'exécution pour accéder aux objets.
Alors j'avoue qu'il y a beaucoup de 'delete' dans mes codes, même récents.
J'apprécie le C++ pour ses possibilités de programmer en bas niveau là où c'est pertinent, et les pointeurs intelligents, c'est déjà une surcouche suspecte dans un code de calcul.
Dans ce type de situation, c'est aussi un peu au programmeur d'être rigoureux dans la gestion de la mémoire, et de comprendre son code. Moyennant quoi, avec l'habitude, j'ai rarement des problèmes de fuite de mémoire (et de plus, je n'utilise pas les exceptions, qui pourraient en générer).
Dès qu'on passe dans les couches supérieures, IHM, gestion de fichier, etc., évidemment, les pointeurs intelligents sont très pratiques et adaptés.

[zobal]

Tu n'as sans doute pas encore lu énormément de mes interventions

Ça doit être cela : je n'ai pas suffisamment étudié ton oeuvre. Si je retourne à l'université un jour, j'essaierais de prendre l'option.

sinon tu saurais que j'aime utiliser des phrases choc pour faire réagir ceux qui me lisent

Dans ce cas, tu ne dois pas être étonné d'avoir réagi à la mienne...

Plus sérieusement, je ne doute pas que tu présentes des idées intéressantes mais je trouve ta façon de les exprimer inutilement verbeuse et moralisatrice. Personnellement, je ne lis plus tes messages qu'en diagonale et préfère passer du temps sur les sites C++ classiques à lire Stroustrup et autres. Mais ce n'est que mon opinion; les goûts et les couleurs...

[foetus]

J'utilise des pointeurs intelligents lorsque celà présente vraiment un intérêt sans inconvénients, mais dans un noyau de calcul intensif, il n'y a que des pointeurs stupides, on ne veut pas d'un niveau d'indirection supplémentaire, de code caché et tests divers qui brisent inutilement le flot d'exécution pour accéder aux objets.

Récemment il y a eu un gros débat sur ce fil de discussion : CppCon 2016 : persuader les programmeurs de C de migrer vers C++

En gros, il n'y a pas d'indirections voire dans certains cas [extrêmes] mieux optimiser parce que comme tout est template alors dans le code final, le compilateur a fait disparaître toutes les capsules RAII et fait 2-3 optimisations (parce qu'il a plus d'informations)

Le gros avantage, c'est la sécurité lors de la programmation: RAII + les capsules RAII, toutes les allocations mémoire sont gérées automatiquement
Le gros inconvénient: apprendre toutes les subtilités du C++ dit moderne.

[wolinn]

Je sais bien que les templates disparaissent à la compilation, mais le compilateur ne va quand même pas éliminer comme ça les compteurs de référence cachés, par exemple, et les tests qui vont avec.
Tu écris bien juste au dessus que l'absence de pénalités sur les pointeurs intelligents dépend d'optimisations du compilateur, et je suis d'accord avec celà. Ce n'est pas une caractéristique du langage imposée par la norme, à ma connaissance. Donc hypothèse à vérifier pour le compilateur utilisé.

[koala01]

Ça doit être cela : je n'ai pas suffisamment étudié ton oeuvre. Si je retourne à l'université un jour, j'essaierais de prendre l'option.

C'est mal barre, je ne suis pas vraiment prof d'unif, ni même maitre de conférence

Dans ce cas, tu ne dois pas être étonné d'avoir réagi à la mienne...

Je ne suis ni étonné ni choqué même par ta réaction, je tiens à te rassurer sur ce point

Je sais parfaitement que je risque des levée de boucliers en écrivant certaines phrases, et j'en accepte l'entière responsabilité

Plus sérieusement, je ne doute pas que tu présentes des idées intéressantes mais je trouve ta façon de les exprimer inutilement verbeuse et moralisatrice.

Verbeuses, très certainement, et je le revendique : j'estime important de permettre à celui qui lit mes réponses de comprendre les tenants et les aboutissants de la solution que je propose.

C'est un choix personnel que j'ai fait depuis longtemps et que j'assume

Moralisatrice, oui, j'assume ausi ce qualificatif ... Mais j'aime que les choses soient bien faites, alors, si je dois passer pour un moralisateur en disant que telle manière de s'y prendre est mauvaise, c'est un risque que j'accepte également pour garantir un minimum de qualité et de pérénité au code que l'on aura basé sur mes interventions

Personnellement, je ne lis plus tes messages qu'en diagonale et préfère passer du temps sur les sites C++ classiques à lire Stroustrup et autres. Mais ce n'est que mon opinion; les goûts et les couleurs...

Comme tu dis, les gouts et les couleurs...

Je pourrais sans doute épiloguer très longtemps pour défendre les raisons qui font que mes interventions sont ce qu'elles sont, mais ce n'est sans doute pas la discussion adéquate. De mon avis, tu ne sais pas ce que tu perds en ne me lisant qu'en diagonale, mais bon... c'est ton opinion, et j'aurai surement du mal à t'en faire changer hein ?

[koala01]

Je sais bien que les templates disparaissent à la compilation, mais le compilateur ne va quand même pas éliminer comme ça les compteurs de référence cachés, par exemple, et les tests qui vont avec.
Tu écris bien juste au dessus que l'absence de pénalités sur les pointeurs intelligents dépend d'optimisations du compilateur, et je suis d'accord avec celà. Ce n'est pas une caractéristique du langage imposée par la norme, à ma connaissance. Donc hypothèse à vérifier pour le compilateur utilisé.

Si ce n'est que le comptage de référence n'a lieu qu'avec std::shared_ptr...

Alors, oui, bien sur, la tentation est grande de décider d'utiliser des shared_ptr pour tout, afin de n'avoir pas à réfléchir à "qui est le propriétaire légal" d'une ressource. Mais c'est en définitive une très mauvaise idée.

La meilleure idée est globalement de partir sur l'utilisation "par défaut" d'un unique_ptr et de ne basculer sur un shared_ptr que si l'on a vraiment pas d'autre choix.

En adoptant cette manière de travailler, le comptage de référence et les tests que cela implique ne pose plus aucun problème, vu qu'il n'y en a pas avec les unique_ptr
[EDIT]En plus, le comptage de référence se fait de manière atomique, si bien que cela se traduit sans doute par une instruction unique ou au pire deux au niveau du code assembleur (incrémentation pour la copie / l'affectation / le lock, decrementation + saut conditionnel dans le destructeur)

Alors, tu me dira qu'il peut y avoir un problème en cas de mauvaise prédiction de la part du processeur, mais à mon avis, ca ne doit pas arriver si souvent que cela (même si je n'ai rien pour étayer ma thèse sur le sujet).

[nikko34]

J'utilise des pointeurs intelligents lorsque celà présente vraiment un intérêt sans inconvénients, mais dans un noyau de calcul intensif, il n'y a que des pointeurs stupides, on ne veut pas d'un niveau d'indirection supplémentaire, de code caché et tests divers qui brisent inutilement le flot d'exécution pour accéder aux objets..

Comme on dit, si tu sais pourquoi tu les utilises...

après c'est pas parce qu'on fait du bas niveau qu'on doit utiliser des pointeurs forcément.. le pointeur d'ailleurs est une indirection et autant utiliser les données directes sans pointeurs quand on peut?

[zobal]

C'est mal barre, je ne suis pas vraiment prof d'unif, ni même maitre de conférence

Je voulais dire que tes interventions semblaient si merveilleuses qu'elles devaient être enseignées dans toutes les universités de France. J'avoue que c'était d'un humour assez douteux.

Je ne suis ni étonné ni choqué même par ta réaction, je tiens à te rassurer sur ce point

Je ne parlais pas de ma réaction mais de la tienne à mon premier message.

De mon avis, tu ne sais pas ce que tu perds en ne me lisant qu'en diagonale, mais bon... c'est ton opinion, et j'aurai surement du mal à t'en faire changer hein ?

C'est beau la modestie... Je ne prétends pas être un dieu du C++ mais je suis loin d'être un débutant, suffisamment pour ne pas avoir appris grand chose de nouveau des quelques interventions de ta part que j'ai quand même lues. Je respecte tout à fait le temps et les efforts que tu consacres ici mais effectivement tu auras du mal à me convaincre de lire tes interventions plutôt que celles de Stroustrup.

Bref, désolé d'avoir fait dériver la discussion. Bonne continuation.

[Luc Hermitte]

La gestion des pointeur nus/bruts, ça ne scale pas. Mais alors, pas du tout. Plus le nombre de chemins d'exécution augmente et plus les chances de pouvoir gérer correctement la mémoire, à la main, sans encourir de fuite s'amenuisent. Avec deux ressources (ou une ressource et des possibilités d'échec) c'est pas trivial de s'en sortir sans RAII, avec 3 ressources (ou 2 avec autres échecs) cela devient très compliqué ou lourd et inefficace, au delà, c'est l'enfer.

Ma démonstration préférée se trouve ici : http://alexandre-laurent.developpez....ou-exceptions/ On y voit successivement des codes à la C, du code C++ au pays magique où les erreurs n'existent pas, un code qui tombe en marche pour le cas particulier présenté mais qui ne supportera aucune évolution de ce code (ajout de ressources ou réorganisations), puis un code à la C qui est correct, et enfin le code C++ correct, simple et qui scale ... sans nuire aux performances.

Quant au prix, s'il est vrai que shared_ptr est loin d'être gratuit, unique_ptr (ou au pire le couple std::auto_ptr et boost:ptr_vector en C++98) ont un surcout totalement négligeable si ce n'est nul.

[camboui]

Intéressante discussion...
J'ai récemment réécrit un vieux code C++ de plus de 15 ans emplumé d'habitudes "C" acquises dans les années 90.

Aujourd'hui j'ai un "beau" code lisible et moderne, mais il consomme 3 fois plus de mémoire et est 15% à 25% plus lent.
La raison est simple, les resources mémoire étaient moindres et il fallait optimiser assez "tôt". Aujourd'hui la disponibilté des resources nous permet de programmer avec une certaine paresse.
Si ça vous interesse je détaille un peu ce qui avait été fait à l'époque "pas propre" mais efficace (avec des horribles pointeurs partout, et des fuites de mémoire volontaires )

Ceci dit, je ne regrette nullement la modernisation du code

[koala01]

Ceci dit, s'il y avait effectivement des fuites mémoires volontaires, ca laisse entrevoir des problèmes sans noms dus à la perte de ressources sur les systèmes anciens

Par contre, pour ce qui est de la lenteur et de l'occupation de la mémoire, peut-être y a-t-il encore "quelque chose" à faire