auto_ptr existe toujours en C++14. C'est en C++17 qu'il est supprim�.Citation:
Envoy� par koala01
http://en.cppreference.com/w/cpp/memory/auto_ptr
Version imprimable
auto_ptr existe toujours en C++14. C'est en C++17 qu'il est supprim�.Citation:
Envoy� par koala01
http://en.cppreference.com/w/cpp/memory/auto_ptr
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 ? ^^
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.
Merci beaucoup
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.
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.Citation:
Envoy� par Oscar.STEFANINI
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 ;)
Ah. Je cuisine g�n�ralement sans rajouter de sel. Par contre les pointeurs intelligents... je m'en sers.
On dirait du Jean-Claude Van Damme, en plus condescendant.Citation:
Envoy� par koala01
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 :? )Citation:
Envoy� par zobal
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.
�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.Citation:
Envoy� par koala01
Dans ce cas, tu ne dois pas �tre �tonn� d'avoir r�agi � la mienne...Citation:
Envoy� par koala01
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...
R�cemment il y a eu un gros d�bat sur ce fil de discussion :whistle: : CppCon 2016 : persuader les programmeurs de C de migrer vers C++Citation:
Envoy� par wolinn
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.
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�.
C'est mal barre, je ne suis pas vraiment prof d'unif, ni m�me maitre de conf�rence ;)Citation:
Envoy� par zobal
Je ne suis ni �tonn� ni choqu� m�me par ta r�action, je tiens � te rassurer sur ce point ;)Citation:
Dans ce cas, tu ne dois pas �tre �tonn� d'avoir r�agi � la mienne...
Je sais parfaitement que je risque des lev�e de boucliers en �crivant certaines phrases, et j'en accepte l'enti�re responsabilit� ;)
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.Citation:
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.
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 ;)
Comme tu dis, les gouts et les couleurs...Citation:
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...
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 ?
Si ce n'est que le comptage de r�f�rence n'a lieu qu'avec std::shared_ptr...Citation:
Envoy� par wolinn
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).
Comme on dit, si tu sais pourquoi tu les utilises...Citation:
Envoy� par wolinn
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?
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.Citation:
Envoy� par koala01
Je ne parlais pas de ma r�action mais de la tienne � mon premier message.Citation:
Je ne suis ni �tonn� ni choqu� m�me par ta r�action, je tiens � te rassurer sur ce point ;)
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.Citation:
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 ?
Bref, d�sol� d'avoir fait d�river la discussion. Bonne continuation.
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.
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 :aie:)
Ceci dit, je ne regrette nullement la modernisation du code :D
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 :P
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 ;)