Discussion :

[Nanoc]

Bonjour à tous.

Ma question est très simple. Peut-on aujourd'hui se passer des pointeurs bruts dans nos codes et les remplacer par des pointeurs intelligents dans tous les cas ?
Il me semble, a priori, que si l'on accepte le petit surcout alors c'est toujours possible.

Si non, qu'est-ce qui nous empêche de le faire ? Avez-vous un exemple concret ?

[peufeu]

Si Truc* CreerTruc( void* p ) créé un objet de classe truc (new Truc) qui garde caché dans sa manche un pointeur sur p, et que tu lui passes un "smart pointer", alors tu as une référence cachée qui traîne, non comptabilisée par ton smart pointer...

Donc, dans tes codes, pourquoi pas, mais dans les codes des autres, attention.

[Astraya]

Une autre chose est que la copie d'un pointeur intelligent "auto_ptr" dé-référence l'original. L'auto_ptr ne répond pas toujours à ce que tu désires.

[Nanoc]

Quand je parle de pointeurs intelligents, je pensais à ceux de boost. En prenant soin de toujours choisir le plus adapté.

[koala01]

Salut,

De manière générale, il est au minimum plus sécurisant d'utiliser les pointeurs intelligents que les pointeurs bruts.

Le temps d'apprentissage est, bien sur, plus important, ne serait-ce que parce qu'il faut commencer par apprendre les différences qui existent entre les différentes possibilités et ce que celles-ci permettent, mais cet investissement est généralement très rapidement amorti en t'économisant énormément de temps de débugage à te demander où se trouve la fuite mémoire ou l'invalidation d'un pointeur, si tu moins, tu choisi... intelligemment tes pointeurs intelligents

Il est, bien sur, possible de s'en passer, mais cela nécessite une politique stricte de la gestion de la mémoire, une conception sans faille et une confiance absolue dans l'équipe de développement.

Je dirais volontiers que plus le projet ou l'équipe devient important(e), plus tu as du "turn over" dans l'équipe, plus la nécessité d'utiliser les pointeurs intelligents se fera sentir

[Joel F]

on peut aussi ne pas utiliser de pointeurs :o

[koala01]

on peut aussi ne pas utiliser de pointeurs :o

On peut, en tout cas, en restreindre énormément l'utilisation, c'est un fait...

Mais il y a certaines situations dans lesquelles leur usage représente, si pas la seule solution, au moins la "moins mauvaise".

C'est à ce moment que l'intérêt des pointeurs intelligents se fera d'autant plus sentir, parce que l'utilisation des pointeurs devient, justement, plus ou moins exceptionnelle et donc... moins maitrisée

[poukill]

on peut aussi ne pas utiliser de pointeurs :o

Globalement difficile quand même.
A partir d'un projet de taille moyenne, on a rapidement une variable membre qui ne peut pas être initialisée à la création et on met un pointeur (intelligent).
Il y a aussi le cas de la responsabilité partagée (ça arrive plus souvent qu'on croit et ça évite d'avoir un méga manager pour toutes les ressources).

D'accord avec toi que les références c'est mieux quand on peut.

[guillaume07]

D'accord avec toi que les références c'est mieux quand on peut.

Pourquoi ?

[koala01]

Pourquoi ?

Pour de nombreuses raisons:

• Les références utilisent une syntaxe identique
• Les références respectent beaucoup plus facilement la constance
• Les références force l'existence de l'objet référencé
• Les pointeurs sont, classiquement, associés à l'allocation dynamique de la mémoire, avec tous les risques que cela peut comporter
• Toutes celles qui ne me viennent pas forcément en tête à cause de l'heure

[guillaume07]

[*]Les références force l'existence de l'objet référencé[/LIST]

et si on initialise la référence sur un pointeur et qu'on delete le pointeur ?

[koala01]

et si on initialise la référence sur un pointeur et qu'on delete le pointeur ?

Généralement, les références sont utilisées en tant qu'argument à une fonction...

La logique utilisée si l'on fournit "ce qui est pointé" par un pointeur lors de l'appel d'une fonction, la libération de la mémoire allouée au pointeur n'interviendra, forcément, qu'après exécution complète de la fonction appelée

Un exemple pour te permettre de comprendre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
/* Soit la fonction */
void foo(Type & ref)
{
    /* on est sur que ref fait bel et bien référence à un objet qui existe */
}
int main()
{
    Type * ptr= new type;
    /* on transmet ce qui est pointé par ptr */
    foo( *ptr);
    /* il n'y a aucun problème à détruire ptr ici, foo a fini de s'exécuter */
    delete ptr;
}

[guillaume07]

exact!

[Nanoc]

Oui donc pour quelqu'un qui débuterait, l'apprentissage utilisation de pointeurs nus n'aurait aucun intérêt.
Et même l'utilisation de pointeurs (intelligents) peut être retardée jusqu'à l'introduction du concept de polymorphisme et de collection hétérogène ainsi que pour ce qui est de l'allocation dynamique.

[JolyLoic]

Oui donc pour quelqu'un qui débuterait, l'apprentissage utilisation de pointeurs nus n'aurait aucun intérêt.

Je trouve ça un peu extrême. Il est certain que je ne commencerais pas par là, mais ça a quand même sa place je trouve dans un cours pour débutants.

Et même l'utilisation de pointeurs (intelligents) peut être retardée jusqu'à l'introduction du concept de polymorphisme et de collection hétérogène ainsi que pour ce qui est de l'allocation dynamique.

C'est à peu près à ce moment là que je les introduits. Et juste après avoir introduit les pointeurs nus, je leur montre comment ils peuvent poser des problèmes, et comment les pointeurs intelligents peuvent gérer ces problèmes.
Mais je passe quand même par l'étape pointeurs nus. Simplement parce que la notion d'une variable qui référence une zone mémoire n'est pas si simple pour tout le monde, et qu'en terme de progression, il me semble utile d'y aller doucement avant d'introduire les notions supplémentaires de responsabilité (éventuellement partagée) de la durée de vie d'une variable, et les mécanismes permettant de gérer cette responsabilité.

Donc, en gros, mon cours fait pointeurs, constructeurs de copie/operateur=, pointeurs intelligents.

[Nanoc]

Oui c'est bien à ça que je pensais.

Et sinon, à part dans l'interfaçage avec des trucs de C qui allouent sans prèvenir, est-ce qu'il y a d'autres limitations ??

[koala01]

Oui donc pour quelqu'un qui débuterait, l'apprentissage utilisation de pointeurs nus n'aurait aucun intérêt.
Et même l'utilisation de pointeurs (intelligents) peut être retardée jusqu'à l'introduction du concept de polymorphisme et de collection hétérogène ainsi que pour ce qui est de l'allocation dynamique.

Je rejoins (un peu tard) l'avis de Loic...

Les pointeurs nus sont malgré tout un passage obligé, ne serait-ce que parce qu'il faut au moins en avoir saisi le principe avant de vouloir expliquer celui des pointeurs intelligents.

On pourrait d'ailleurs très facilement scinder les explications sur les pointeurs en deux temps:

• Dans un premier temps, se contenter de dire ce que c'est, afin de permettre (c'est parfois nécessaire ) de référencer le contenant dans le contenu
• Dans un deuxième temps expliquer leur utilisation dans l'allocation dynamique de la à but de polymorphisme.

Les pointeurs intelligents arrivant, oserais-je écrire fatalement , comme solution aux problèmes que peuvent poser les pointeurs nus face à l'allocation dynamique de la mémoire

Et puis, il faut aussi apporter une certaine tempérance en fonction du contexte:

Au risque de paraître bien modeste, la maitrise que j'ai des pointeurs, et le haut niveau ma conception et de ma logique fait que je suis sur de travailler correctement avec des pointeurs nus.

Pour un projet d'application tout à fait personnel, je ne me forcerai pas vraiment à utiliser les pointeurs intelligents

Par contre, pour un projet personnel de bibliothèque, qui sera susceptible d'être utilisée par d'autres, ou pour un projet d'équipe, je sortirai les pointeurs intelligents si vite que tu n'auras pas le temps de dire ouf, simplement, parce que je ne serai plus dans une situation dans laquelle je peux assurer la qualité de ce qui est fait.

On ne peut obliger personne, lors d'une discussion générale comme celle-ci à utiliser les pointeurs intelligents, et tu remarqueras d'ailleurs qu'on a bien évité de le faire .

Par contre, il est important de te donner les informations qui te permettront de prendre ta décision "en connaissance de cause".

Le meilleur moyen d'y arriver est de te parler, comme je l'ai fait, des avantages, des inconvénients et des risques de chaque méthode .

[koala01]

Oui c'est bien à ça que je pensais.

Et sinon, à part dans l'interfaçage avec des trucs de C qui allouent sans prèvenir, est-ce qu'il y a d'autres limitations ??

L'allocation, c'est encore le moindre mal...

Ce qui fait tout de suite beaucoup plus de mal, c'est une désallocation sans prévenir.

D'une certaine manière, si tu refais un new sur un pointeur pour lequel la mémoire a déjà été allouée dynamiquement, " tout ce que tu risque" , c'est une fuite mémoire.

Ce n'est pas bien, c'est mauvais pour le système, mais, au vu des systèmes actuels, tu peux encore avoir une certaine tolérance par rapport à cela (comprend moi: je ne dis pas qu'il ne faut pas s'en faire, je remarque simplement qu'il faut déjà perdre souvent la référence à une adresse mémoire ou allouer de grosses quantités de mémoire avant de mettre le système en péril )

Par contre, la libération de la mémoire allouée dynamiquement sans avoir la certitude que tous ceux qui disposent de l'adresse soient bien tenus au courent va se payer très cher et comptant: toute tentative d'accès à l'adresse après la libération, ou de nouvelle libération de la mémoire, enverra le programme cueillir les pâquerettes, avec plantage quasi immédiat de l'application (dans le meilleur des cas).

Tout ce qui pourra éviter de se trouver dans ce genre de situation sera donc réellement le bienvenu

[NoIdea]

Personnellement, j'utilise beaucoup les pointeurs nus dans le "fouillis interne" de ma classe : Dans ce qui est public, pas de pointeurs mais dans tous ce qui est interne à une classe, j'utilise presque exclusivement les pointeurs nus.
Les pointeurs intelligents, sont tout de même conseillé lors de fonctions non membre et quand les performances ne sont pas cruciales.
De plus, j'aurais tendance à dire, que moins on est à travailler sur un projet, plus on peut se permettre les pointeurs nus.

[poukill]

Les pointeurs intelligents, sont tout de même conseillé lors de fonctions non membre et quand les performances ne sont pas cruciales.

Pas d'accord du tout. La pénalité de performance est extrêmement faible. Tu l'as déjà mesurée ? C'est l'impleméntation d'un compteur de référénce pour le shared_ptr.

De plus, j'aurais tendance à dire, que moins on est à travailler sur un projet, plus on peut se permettre les pointeurs nus.

Euh... Perso je suis souvent tout seul, et les shared_ptr sont mes amis. Non seulement, j'arrive rapidement à garantir un minimum d'exception safety dans mes classes, mais j'arrive aussi à écrire presque du premier coup un code qui marche, et sans fuite mémoire. Dans un code avec plus de 100 000 lignes, auquel il faut ajouté la dépendance à une dizaine de librairies, le tout baignant dans les exceptions (c'est bien là le fond du problème), va jouer là dedans avec des pointeurs tout nus !
Le sujet a déjà été largement traité, je vais pas me répéter, mais un coup d'oeil dans un bon bouquin du genre Exceptional C++, et tu vas les aimer les pointeurs intelligents.