Discussion :

[Flob90]

@koala: Ca a quand même clairement l'air d'être le cas en C d'après la citation de 3DArchi, à moins que tu interprêtes d'une autre manière ? Après c'est focément légèrement différent en C++ (cf ce que j'ai dit avant) et c'est peut-etre la désallocation de la zone pointée que la destruction de la variable qui marque l'invalidité des pointeurs.

[gl]

Mais, cependant, ce n'est pas le seul fait d'essayer de lire l'adresse maintenue par un pointeur devenu invalide qui va provoquer un comportement indéterminé, autrement, un simple test proche de if(ptr) provoquerait directement un comportement indéterminé, ainsi que je l'ai déjà indiqué

Non, if(ptr) ne poserait aucun problème si ptr contient une adresse valide ou NULL.

[koala01]

Mais, justement, le comportement ne devient pas pour autant indéfini si, pour une raison ou une autre, ptr pointe vers... une adresse correspondant à un objet détruit.

Ce n'est que par après que le comportement indéfini survient... lorsque l'on essaye de déréférencer ce pointeur, tou d'accéder à n'importe quelle adresse calculée sur base de celui-ci.

[Flob90]

Le problème c'est que justement la norme C dit que le pointeur ne pointera plus forcément vers où était l'objet avant ca destruction. Alors en effet c'est pas un UB en soit, c'est pas pour autant le comportement auqeul on pourrait s'attendre. (et ca explique le problème de départ en plus).

[Médinoc]

Ça, c'est le raisonnement "intuitif". Mais on m'avait justement dit, sur ce même forum, que le vrai comportement était contraire à l'intuition.

[3DArchi]

Ça, c'est le raisonnement "intuitif". Mais on m'avait justement dit, sur ce même forum, que le vrai comportement était contraire à l'intuition.

Entièrement d'accord. J'avais le même souvenir de discussion, je l'ai cherchée mais pas trouvée. Et c'était clairement dit que le simple fait de lire la valeur pouvait provoquer un trap.