Discussion :

[sc_wizard29]

Bonjour les gens !

Après 8 ans de Java, j'essaie tant bien que mal de me remettre au C++, mais le petit bout de code suivant me pose bien des soucis :

class1.cpp

Code :

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

1
2
3
 
#include "class1.h"
Class1::Class1() { }

class2.cpp

Code :

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

1
2
3
4
 
#include "class2.h"
Class2::Class2() { }
Class2::~Class2() { }

main.cpp

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
 
#include "class1.h"
#include "class2.h"
#include <iostream>
#include <cassert>
 
void* ptr;
 
Class1 test1() {
    Class1 class1;
    ptr = &class1;
    return class1;
}
 
Class2 test2() {
    Class2 class2;
    ptr = &class2;
    return class2;
}
 
int main(int argc, char *argv[]) {
    Class1 class1 = test1();
    assert (ptr != &class1);
    Class2 class2 = test2();
    assert (ptr == &class2);
}

Comme vous pouvez le voir aux deux assertions :
- dans un cas l'instance de Class1 renvoyée par test1() est DIFFERENTE de celle instanciée dans test1()... et je dis ça parce que les adresses en mémoire sont différentes : cf premier "assert".
- dans l'autre cas, l'instance de Class2 renvoyée par test2() est LA MEME que celle instanciée dans test2() : cf deuxième "assert".

Pourtant, la seule différence entre Class1 et Class2 est le fait que dans j'ai explicitement défini le destructeur dans Class2 !

Si quelqu'un pouvait m'expliquer ce comportement curieux, ça m'éviterait de passer une nouvelle nuit blanche

Merci beaucoup par avance !

[Arzar]

Bonjour,

Quand tu récupères l'adresse de class1 et de class2 dans test1() et test2(), tu récupères une adresse sur des objets locaux qui sont détruits en sortant de la fonction.

Donc réutiliser cette adresse après avoir quitté la fonction est un comportement indéfini. Pas besoin de passer des nuits blanches, les résultats n'ont aucune réelle signification et varieront d'un compilateur à l'autre.

[sc_wizard29]

Effectivement, c'est l'explication la plus plausible... merci pour ton aide Arzar !

[koala01]

Salut,

C'est bizare, chez moi, le code

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
27
#include <iostream>
class Class1
{
    public:
        Class1(){std::cout<<"Construction d'origine"<<std::endl;}
        Class1(Class1 const & )
        {std::cout<<"Construction par copie"<<std::endl;}
        Class1 & operator=(Class1 const & )
        {std::cout<<"affectation avec l'operateur egal"<<std::endl;
         return *this;}
        ~Class1(){std::cout<<"destruction"<<std::endl;}
};
Class1 * ptr;
Class1 test()
{
    Class1 c;
    std::cout<<"recuperation de l'adresse ("<<std::hex<<&c<<")"<<std::endl;
    ptr = &c;
    return c;
}
int main()
{
    Class1 t= test();
    std::cout<<"adresse de t :"<<&t<<std::endl;
    std::cout<<ptr<<std::endl;
    return 0;
}

fonctionne sans aucun problème chez moi (Serait-ce NRVO qui faire des siennes ) avec comme résultat

Code :

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

1
2
3
4
5
creation d'origine
recuperation de l'adresse (0x22fd9f)
adresse de t : 0x22fd9f
adresse pointee par ptr : 0x22fd9f
destruction

On assiste à la destruction (!!!) de l'objet avant sa copie lorsque test renvoie... une référence (ou une référence constante)

Bonjour,

Quand tu récupères l'adresse de class1 et de class2 dans test1() et test2(), tu récupères une adresse sur des objets locaux qui sont détruits en sortant de la fonction.

Oui, mais non...

Les objets identifiés par les variables dans test1 et dans test2 sont... renvoyés par la fonction, et récupérés dans main...

Tu aurais destruction de l'objet créé dans test1 et dans test2 si tu renvoyais une référence sur celui-ci et non une valeur

Tu aurais alors copie de... l'objet après sa destruction, et, fatalement, les adresses ne correspondraient pas.

Donc réutiliser cette adresse après avoir quitté la fonction est un comportement indéfini. Pas besoin de passer des nuits blanches, les résultats n'ont aucune réelle signification et varieront d'un compilateur à l'autre.

C'est vrai si

• l'objet n'est pas renvoyé ou si
• l'objet est renvoyé sous forme d'une référence (éventuellement constante).

Ceci dit, il ne faut pas confondre: la valeur représentée par ptr peut être considérée comme une valeur valide, parce qu'elle représente, effectivement, une adresse correcte.

Par contre, ce sont les tentative de déréférencement en dehors de la fonction (en appelant "ce qui est pointé" par le pointeur) qui provoqueront un comportement indéfini, parce que l'adresse correspond à... celle d'un objet qui a été détruit

[Flob90]

@koala:

Pourtant, la seule différence entre Class1 et Class2 est le fait que dans j'ai explicitement défini le destructeur dans Class2 !

En gros tu viens de faire son test avec class2 qui comme lui marche, enlève le destructeur (ou mets le en default) et retestes, apparament c'était ca qui induisait un comportement different

[Flob90]

Je vient de tester, et j'arrive au même résulat, j'ai aussi tester avec d'autre fonction spécial (constructeur), pour voir si c'était pas un comportement spécifique aux POD par exemple.

Mais apparament la seule condition qui fait échouer l'égalité c'est l'absence d'un destructeur user-define et non default pour la classe et pour toutes les classes de base et des classes des attributs.

[3DArchi]

Salut,
La réponse d'Arzar était la bonne : comportement indéterminé ! Visual C++ Express et GCC (mingw) ne me donnent pas le même résultat.

[Flob90]

Se baser sur le comportement de deux compilateurs pour dire que c'est un UB c'est un peu fort, il y a peut-etre un des deux compilateurs qui ne respecte pas la norme sur ce point ! (ceci dit j'ai rien trouvé dans le draft )

[NoIdea]

En théorie, on a Class1 t=test1(); On devrait donc avoir un operator= appelé dans class1 mais ce n'est pas le cas (comme le montre le code de koala).
On pourrait imaginer, dans une optique d'optimisation que ce code devienne
Class1 t(test1());

mais dans le code montré par koala, on ne voit pas d'appel on constructeur de copie.

Donc que fais le compilateur ? Je pense qu'en fonction des options de compilations et du compilateur, les optimisations mènent a des comportement différents.

[3DArchi]

Se baser sur le comportement de deux compilateurs pour dire que c'est un UB c'est un peu fort, il y a peut-etre un des deux compilateurs qui ne respecte pas la norme sur ce point ! (ceci dit j'ai rien trouvé dans le draft )

Effectivement ce n'est pas une preuve.
En retour de la fonction, rien ne te dit sur ce que fait l'exécutable de la zone mémoire locale. L'un peut avoir récupérer la pile, l'autre optimisé. Bref, rien de prévisible. Néanmoins, il me semble lire l'adresse d'un objet invalide même si on ne la déréférence pas reste un comportement indéterminé.

[Flob90]

@NoIdea: Non ca devrait toujours être le constructeur de copie qui est appelé, pas l'opérateur d'affectation (ce n'est pas parce que tu vois = que c'est l'opérateur d'affectation cf faq ) Et si je me trompe pas la raison pour laquel il n'y a pas d'appel au constructeur de copie c'est le (N)RVO (comme koala l'a dit) et oui ca doit se désactiver dans les options de ton compilateur.

@3DArchi: Oui je suis d'accord il doit surment il y avoir un comportement indeterminé là-dessous (ca me semble gros que gcc ne respecte pas la norme sur un point comme celui-ci), je trouve quand même étonnant un comportement différent selon la présence ou non d'un destrcuteur user-define, mais bon c'est le propre d'un UB d'être imprévisible

Ou comme le dit koala c'est peut-etre du au NRVO, qui décide de contruire directement l'objet à un autre emplacement (à la place de copier) d'ou la différence dans les addresse. Après pourquoi le comportement diffère avec le destructeur ...

[koala01]

Effectivement ce n'est pas une preuve.
En retour de la fonction, rien ne te dit sur ce que fait l'exécutable de la zone mémoire locale. L'un peut avoir récupérer la pile, l'autre optimisé. Bref, rien de prévisible. Néanmoins, il me semble lire l'adresse d'un objet invalide même si on ne la déréférence pas reste un comportement indéterminé.

Lire l'adresse d'un pointeur n'aura jamais un comportement indéterminé, que l'adresse soit valide, qu'elle passe pour l'être ou qu'elle soit connue pour ne pas l'être (comprend: que l'objet pointé existe, qu'il ait été détruit proprement ou que le pointeur vaille NULL)

Autrement, un test if(ptr == NULL) aurait... un comportement indéterminé, ce qui serait quand même un comble

Le comportement indéterminé surviendra quand... tu essayera d'accéder à cette adresse

maintenant, nous sommes tous d'accord sur le fait qu'une tentative de déréférencement sera sans doute l'étape venant tout juste après avoir vérifié la valeur numérique de l'adresse (ne serait-ce qu'en testant qu'elle ne soit pas nulle)

[3DArchi]

Lire l'adresse d'un pointeur n'aura jamais un comportement indéterminé, que l'adresse soit valide, qu'elle passe pour l'être ou qu'elle soit connue pour ne pas l'être (comprend: que l'objet pointé existe, qu'il ait été détruit proprement ou que le pointeur vaille NULL)

La valeur nulle est une valeur spéciale. Mais, sinon, dans la norme C, je trouve :

The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address, and retains its last-stored value throughout its lifetime. If an object is referred to outside of its lifetime, the behavior is undefined. The value of a pointer becomes indeterminate when the object it points to reaches the end of its lifetime.

La norme C++ pour ce point (3.8 Object Lifetime) ne précise que ce qui est possible ou pas entre la fin du destructeur et la libération de la zone mémoire. Peut être que je me trompe, mais je pense que dès lors que la zone mémoire est libérée, on doit pouvoir se référer au comportement C : la valeur du pointeur est indéterminé. Après, dans les implémentations de type PC, ça se content juste de pointer une zone invalide mais pas sûr qu'il n'y ait pas des plateformes plus exotiques où cela serait problématique.

[koala01]

Ce que je veux dire, c'est que l'adresse en elle-même reste... celle à laquelle se trouvait l'objet.

Et cette adresse reste malgré tout... une adresse accessible et donc "considérable comme valide".

Tu peux donc lire cette adresse, éventuellement l'afficher, cela ne provoquera aucun comportement indéterminé.

Par contre, dés que tu essaye d'accéder à l'adresse, ou à toute adresse mémoire calculée sur base de l'adresse représentée, il est clair que tu provoquera un comportement indéterminé.

C'est donc bel et bien l'accès à l'adresse (le déréférencement du pointeur) qui provoque le comportement indéterminé, et non... le simple fait de... l'utiliser comme valeur numérique, avec les possibilités de tests et de comparaison qu'elle permet

[EDIT]Et De plus, même si NULL est une valeur particulière, elle correspond également à false et on peut donc effectuer un simple test if(ptr)... dans lequel NULL n'apparait purement et simplement pas.

On ne pourrait donc pas se fier à un tel test si, pour la "seule raison" que l'objet a été détruit, l'acces en lecture à cette valeur (et non à ce qui se trouve à l'adresse que représente cette valeur) provoquait un comportement indéterminé

[3DArchi]

On ne pourrait donc pas se fier à un tel test si, pour la "seule raison" que l'objet a été détruit, l'acces en lecture à cette valeur (et non à ce qui se trouve à l'adresse que représente cette valeur) provoquait un comportement indéterminé

The value of a pointer becomes indeterminate when the object it points to reaches the end of its lifetime.

[Arzar]

Bon je savais que l'emploi du terme "comportement indéfini" était incorrect, mais j'ai eu la flemme de reformuler la phrase. My bad.

Donc pour être plus précis la valeur d'un pointeur sur un objet ayant expiré est indéfini. Car l'objet en question peut n'avoir jamais existé !
Et effectivement, dans le cas de sc_wizard29 je pense que l'on voit dans le deuxième cas une RVO (un seul objet créé) alors que dans le premier cas non (une copie créée)

Mais je n'avais pas trop envie de le perdre sur des détails, car fondamentalement il ne faut pas se fier à un pointeur sur un objet expiré pour en déduire des généralités.

Oui, mais non...

Les objets identifiés par les variables dans test1 et dans test2 sont... renvoyés par la fonction, et récupérés dans main...

Tu aurais destruction de l'objet créé dans test1 et dans test2 si tu renvoyais une référence sur celui-ci et non une valeur

Tu aurais alors copie de... l'objet après sa destruction, et, fatalement, les adresses ne correspondraient pas.

Je ne comprends pas de quoi tu parles koala.
Le comportement normal c'est :

1) création de l'objet temporaire dans la fonction.
Puis en sortant de la fonction :
2)création de l'objet dans le main par copie-construction de l'objet temporaire
3) destruction de l'objet temporaire.

MAIS les compilateurs ont toutes latitudes pour générer le code qu'ils veulent tant que le programme exhibe un comportement identique à ce que l'on verrait s'il respectait la séquence ci-dessus. En particulier ils peuvent optimiser et sauter complètement la phase de création de l'objet temporaire (RVO). Et ils sont protégés par le standard contre les pointeurs globals malicieux comme le cite 3DArchi.

[Flob90]

J'ai rien trouvé dans la norme C++, mais c'est certain que la phrase que tu cites n'est plus valable en C++, la vie d'un objet s'arrete quand le destructeur est appelé, or quand on utilise un allocateur spécifique, on appele explictement le destructeur via un pointeur et après on désalloue l'espace via le même pointeur. Et c'est parfaitement déterminé.

La seule chose que j'ai trouvé c'est ca :

For an object with a non-trivial constructor, referring to any non-static member or base class of the object
before the constructor begins execution results in undefined behavior. For an object with a non-trivial
destructor, referring to any non-static member or base class of the object after the destructor finishes
execution results in undefined behavior.

(section 12.7, draft n3090)
Mais je ne crois pas que ca soit d'une grande aide ici (mais ca montre un des différences de comportement entre destructeur trivial et non trivial).

[3DArchi]

J'ai rien trouvé dans la norme C++, mais c'est certain que la phrase que tu cites n'est plus valable en C++

J'aurais tendance à la comprendre comme quoi la valeur du pointeur est indéterminée dès lors que l'espace associé a été libéré (explicitement ou automatiquement).

[Médinoc]

Je me souviens qu'on m'avait déjà dit un truc de ce genre sur le forum C: Une fois que la donnée pointée n'est plus valide, le seul fait de lire le pointeur lui-même (sans même le déréférencer) cause un comportement indéterminé.

Par exemple, une architecture exotique pourrait automatiquement vérifier la validité de tout pointeur au moment où il est mis dans un registre d'addresse, et lancer une exception.

[koala01]

Je me souviens qu'on m'avait déjà dit un truc de ce genre sur le forum C: Une fois que la donnée pointée n'est plus valide, le seul fait de lire le pointeur lui-même (sans même le déréférencer) cause un comportement indéterminé.

Il ne faut pas oublier qu'un pointeur n'est, jamais, qu'une valeur numérique entière "classique" dans le sens où l'on peut la comparer avec une autre, ou la manipuler arithmétriquement.

Vous me direz qu'il s'agit, aussi, d'une valeur particulière dans le sens où cette valeur représente l'adresse mémoire à laquelle on trouve la variable du type indiqué.

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é