Discussion :

[Invité]

Bonjour,

Faisant suite à mon apprentissage de c++ et les pointeurs, je me pose la question suivante.
Est ce que l'utilisation d'un d'un nullptr après un delete sur un pointeur est-il recommandé ou superflu?

Pour exemple dans ce code partiel pour ma compréhension personnel, j'ai :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
 
class Test {
public:
    Test();        
    ~Test(); 
 
 
 
private:
    int *aAge;
    int *aWeight;
};
 
Test::Test() {
    aAge = new int(5);
    aWeight = new int(9);
}
 
Test::~Test() {
    delete aAge;
    aAge = nullptr;
 
    delete aWeight;
    aWeight = nullptr;
}

Les différents débugs que j'effectue me monte une simple adresse à zéro, qui n'existe pas sans le nullptr.

Merci

[foetus]

Est ce que l'utilisation d'un d'un nullptr après un delete sur un pointeur est-il recommandé ou superflu?

cela va dépendre si ta variable / propriété est utilisée après ou pas (... par analogie si ta variable est locale ou pas)

Parce qu'après, comme la majorité des tests sont basés sur des tests NULL, 1 variable détruite passera le test avec 1 adresse pointant vers de la mémoire libérée.
Mais par simplicité, on le fait automatiquement

[skeud]

C'est une bonne pratique à faire.

La plupart des codes complexe vont avoir une allocation dynamique et volatile de la mémoire. Le fait de passer ton pointeur à nullptr peut te permettre de tester ton pointeur avant l'execution d'un code.

Prenons par exemple le cas d'une classe avion qui possède un attribut de type missile.

Lors de l'initialisation, on créé le missile (allocation de la mémoire) puis pendant le vol, l'avion le tire (on retire donc le missile, soit par un delete car on l'utilise pas, soit en déplaçant le pointeur dans une autre classe qui s'occupera de faire voler le missile).

A partir de là, mettons que tu veuille savoir si un missile est toujours disponible pour être tiré. tu vas tester le pointeur, si tu n'as pas mis nullptr auparavant, ça va poser des soucis .

[Invité]

Bonjour et merci pour vos réponses.

Ayant encore un peu approfondi mon apprentissage, mes recherches et mes tests, je me rends compte que cela n'est pas toujours utile.

Dans mon exemple de code précédent, je crois comprendre que suite à la destruction de mon objet test il n'est pas nécéssaire d'utiliser le nullptr après le delete des objets contenu dans ma classe. Par contre lors de la destruction de mon objet test, il était logique que je le fasse.

[Bousk]

La bonne pratique c'est d'utiliser std::unique_ptr.
Enfin dans ce cas simple la bonne pratique c'est de ne surtout pas utiliser de pointeurs...
Un pointeur nu c'est réservé à des références optionnelles ou dont tu peux changer la valeur, si tu ne peux/veux pas utiliser std::reference_wrapper.

[skeud]

Un pointeur nu c'est réservé à des références optionnelles ou dont tu peux changer la valeur.

Ou dans les sociétés qui n'ont pas visual 2015 ou sur du code legacy, c'est pour ça que j'encourage souvent à commencer par les pointeur nus, pour ensuite passer aux pointeurs intélligents, comme ça on maitrise ce qu'on fait .

[Invité]

Ou dans les sociétés qui n'ont pas visual 2015 ou sur du code legacy, c'est pour ça que j'encourage souvent à commencer par les pointeur nus, pour ensuite passer aux pointeurs intélligents, comme ça on maitrise ce qu'on fait .

Je suis effectivement dans cette pratique de la base (en sup de mes cours) avec par la suite le c++ moderne pour une bonne compréhension (j'espère) de ce que je fais.

Merci

[jo_link_noir]

Cette histoire de « on maîtrise ce qu'on fait parce que c'est plus bas niveau » est de mon point vu complètement faux. Les pointeurs intelligents existent pour résoudre des problèmes qu'il est humainement impossible d'éviter: la garantie que le pointeur sera libéré dans tous les chemins de code. Chaque appel de fonction peut faire une exception et se sont autant de chemin de code qui amènent à des fuites mémoires potentielles. Si on explique l'allocation dynamique avec les pointeurs C, il faut expliquer ce qu'est un pointeur, ce qu'est l'allocation dynamique et ce que sont les exceptions.

Ensuite inévitablement viennent les nombreuses erreurs de double libération, de fuite mémoire et de dangling pointer. Il faut parler du principe d'unicité, d'ownership, de bonne manière de libérer et du pourquoi il faut remettre le pointeur à nul ou pas. Insister sur le fait qu'un container de pointeur alloué dynamiquement ne se libère pas tout seul, qu'il faut des posts traitement à chaque suppression et chaque modification de valeur. Réexpliquer pourquoi cela ne fonctionne pas bien avec les exceptions, introduire la notion de RAII et finalement refaire un pointeur intelligent.

En parlant de pointeur intelligent, on peut ignorer les exceptions et se passer des post-traitements et de remise à zéro. Les fuites mémoires, dangling pointer et double free sont normalement inexistants (du moment qu'on ne s'amuse à récupérer le pointeur sous-jacent). On a des vérifications par le compilateur/classe pour tout ce qui concerne l'ownership à travers des types sémantiques. Finalement, il y a beaucoup moins à apprendre d'un coup et le principe clef de qui est propriétaire de quoi est bien plus mis en évidence.

Quand on a compris ça en peut revenir sur l'enfer qu'est le pointeur brut alloué dynamiquement et le maudire.