Discussion :

[PilloBuenaGente]

Bonjour,
Dans ce code mon compilo ne me dit rien alors qu'il devrait m'interdire cette manière?!

Je stocke les références d'objets temporaire dans une liste.

Mission.h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#include "Date.h"
#include "Time.h"
 
class Mission {
public:
        Mission( const Date& date, const Time& time ) : date( date ),
                                                        time( time ) {
        }
 
private:
        const Date& date;
        const Time& time;
};

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
#include "Mission.h"
#include <list>
 
int main()
{
        std::list < Mission > mission;
 
        if( 1 ) {
                Date date( 1, 1, 2000 );
                Time time( 2, 30 );
 
                mission.push_back( Mission( date, time ));//Nouvelle mission avec les adresses de date et time
 
        }//Les instances Time et Date sont censées ce détruire ici ?!
 
        return 0;
}

Les références "sauvegardent" t-elles les objets en mémoire ? (!!Les références évitent les copies!!??)

Ou bien mes références continuent d'exister le temps que leur emplacement en mémoire reste non modifié ?

Ou je ne sais quoi ..

Merci d'avance !

[Neckara]

Bonjour,

La FAQ pourrait déjà te donner quelques informations.

Sinon, si l'objet référencé par la référence est détruite et que tu tentes d'utiliser la référence pour accéder à l'objet, tu auras une segfault car la mémoire aura été libérée.

[Ehonn]

C'est pire qu'une erreur de segmentation, c'est un comportement indéterminé (?).

[PilloBuenaGente]

Ok merci bien !


#EDIT

c'est un comportement indéterminé (?)

Donc ce problème peut arriver n'importe quand !?

Éviter cette manière sans doute !

Merci

[Ehonn]

Donc ce problème peut arriver n'importe quand !?

Le problème arrive uniquement lorsqu'on l'a écrit; et lorsque l'on rencontre, il peut se passer n'importe quoi (le mieux étant une erreur de segmentation).

[Neckara]

Oui, quand je dis segfault c'est un raccourcit un peu facile, on est pas toujours sûr à 100% qu'on aura bien le signal SIGSEG.

On peut en effet taper dans l'espace mémoire de notre programme et ne pas faire planter le programme. C'est pour cela que le comportement est indéterminé.

Mais c'est aussi le cas pour toutes les erreurs générant une segfault (?), ainsi il me semble que toute erreur de segfault provient d'un comportement indéterminé (?).

[Ehonn]

Mais c'est aussi le cas pour toutes les erreurs générant une segfault (?), ainsi il me semble que toute erreur de segfault provient d'un comportement indéterminé (?).

Oui (pour la norme C, y compris le déréférencement d'un pointeur NULL).

[koala01]

Salut,

Oui, quand je dis segfault c'est un raccourcit un peu facile, on est pas toujours sûr à 100% qu'on aura bien le signal SIGSEG.

On peut en effet taper dans l'espace mémoire de notre programme et ne pas faire planter le programme. C'est pour cela que le comportement est indéterminé.

Mais c'est aussi le cas pour toutes les erreurs générant une segfault (?), ainsi il me semble que toute erreur de segfault provient d'un comportement indéterminé (?).

Pour être précis:

Il y a de fortes chances qu'un comportement indéfini soit l'origine d'une erreur de segmentation, mais:

1. L'erreur de segmentation survient lorsque l'on essaye d'accéder (de préférence en écriture) à une adresse invalide, et une adresse invalide peut etre due à tout autre chose qu'à un comportement indéfini
2. Un comportement indéfini peut avoir bien d'autres conséquences qu'une erreur de segmentation

A titre d'exemple:
pour le (1) appeler delete sur un pointeur vers un objet créé à l'aide de new est un comportement totalement défini.

Si l'on n'a pas fait en sorte que le pointeur en question pointe sur NULL (nullptr en C++11), ou si on ne teste pas la valeur du pointeur avant d'y accéder en écriture, nous aurons une erreur de segmentation.

Bon, d'accord, le fait d'accéder en écriture à une adresse invalide provoque, me semble-t-il, un comportement indéfini.

Mais si on essaye d'y accéder en lecture, nous aurons, effectivement, un comportement indéfini qui peut provoquer du grand tout et n'importe quoi:

• L'affichage des données peut être simplement correct, tout comme il peut avoir des résultats aberrants
• Si on utilises les informations obtenue pour d'autres calculs, va savoir ce que l'on obtiendra au final

Pour le (2), il faut juste se dire que les auteurs de la norme ont bien conscience du fait que C++ est multi plateformes, multi os, multi plein de choses

L'idée du comportement indéfini réside dans le fait qu'ils n'ont simplement pas su déterminer ce qui pouvait se passer, tout en sachant que, quoi qu'il advienne, ce ne serait surement rien de bon, et de laisser le choix de ce qu'il faut faire aux créateurs de compilateurs

Lancer un SIGSEGV (un signal d'erreur de segmentation) est une solution parmi tant d'autres qui s'applique très bien à certains comportements indéfinis, mais rien n'empêcherait un créateur de compilateur de faire en sorte de lancer une expression ou... de lancer la commande format c:

Le jour où un créateur de compilateur choisira cette option, les gens commenceront peut etre à être plus attentifs à les éviter