Etrange bug de tableau

Version imprimable

Bonjour,

J'ai un étrange bug quand je déclare un tableau c++, selon l'endroit ou il est déclaré mon appli plante ou non.La tableau qui pose probleme est datedeRH[NBMAX], Voici mon code :

Code:

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
 
#pragma once
#include <string.h>
#include <iostream>
#define NBMAX 450
 
 
class Liste
{
    private :
    std::string numdeRH[NBMAX];
 
    std::string numdeSCD[NBMAX];
    int datedeSCD[NBMAX]; 
    int datedeRH[NBMAX]; // Déclaré ici,il n'y a aucun problème
 
 
 
    public :
    Liste();
    void recupnumbaseRH();
    void recupnumSCD();
    void compare();
 
};

Mais quand je change le position de la déclaration du tableau dateRH[NBMAX]

Code:

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
 
#pragma once
#include <string.h>
#include <iostream>
#define NBMAX 450
 
 
class Liste
{
    private :
    std::string numdeRH[NBMAX];
    int datedeRH[NBMAX]; // Mais quand il est déclaré ici l'appli se compile mais plante comme un dépasement de tableau
    std::string numdeSCD[NBMAX];
    int datedeSCD[NBMAX]; 
 
 
 
 
    public :
    Liste();
    void recupnumbaseRH();
    void recupnumSCD();
    void compare();
 
};

Vous avez une idée de pourquoi le tableau plante ?J'utilise Code::Blocks

Merci :)

24/11/2009, 09h36
3DArchi

Salut,
Éventuellement, ça peut être un problème de pile. Comment instancies-tu une variable de type Liste pour déclencher le problème ?

Voila l'instanciation d'un objet Liste
Code:

1 2 3 4 5 6 7 8 9 int main() { Liste l; l.recupnumbaseRH(); l.recupnumSCD(); l.compare(); }

24/11/2009, 10h23
3DArchi

A quel moment ça plante ?
24/11/2009, 10h32
anthonyplay

Lors de la compilation il n'y a aucun problème, mais l'appli plante à son exécution et windows affiche un message d'erreur de mémoire qui ne peut pas être "written", ce qui ressemble à un bug de dépassement de tableau.
24/11/2009, 11h03
3DArchi

Oui ca ressemble à ça. Mais ça plante avant d'entrer dans le main ou dans une de tes fonctions ?
24/11/2009, 11h09
anthonyplay

Comment le savoir puisque la compilation ne retourne aucun plantage ?
24/11/2009, 11h12
Syl_20

Citation:

Envoyé par anthonyplay

Comment le savoir puisque la compilation ne retourne aucun plantage ?

met un point d'arrêt à l'entrée du main et fait une exécution pas a pas pour voir à quelle ligne sa plante.

Citation:

Envoyé par Syl_20

met un point d'arrêt à l'entrée du main et fait une exécution pas a pas pour voir à quelle ligne sa plante.

C'est la meilleur solution : apprendre à utiliser son debugger.

Sinon, tu peux aussi utiliser des traces :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 int main() { std::cout<<"Debut de main\n"; Liste l; std::cout<<"Appel de recupnumbaseRH\n"; l.recupnumbaseRH(); std::cout<<"Appel de recupnumSCD\n"; l.recupnumSCD(); std::cout<<"Appel de compare\n"; l.compare(); std::cout<<"Fin !\n"; return 0; }
Puis tu affines là où ça plante.

bonjour,

peut-être que je me trompe mais comme Liste est une classe, je l'aurai déclaré de cette manière :
Code:

1 2 3 4 5 6 7 8 Liste *L = new Liste(); L->recupnumbaseRH(); L->recupnumSCD(); L->compare(); delete L;
non ?

Dans les méthodes publiques j'aurai rajouté en plus le destructeur :
Code:

1 2 3 4 5 6 Liste(); ~Liste(); void recupnumbaseRH(); void recupnumSCD(); void compare();

Salut,
Citation:
Envoyé par Auteur
bonjour,

peut-être que je me trompe mais comme Liste est une classe, je l'aurai déclaré de cette manière :
Code:

1 2 3 4 5 6 7 8 Liste *L = new Liste(); L->recupnumbaseRH(); L->recupnumSCD(); L->compare(); delete L;
non ?
Pas forcément...

Il est tout à fait autorisé (et bien souvent conseillé, d'ailleurs) de ne recourir à l'allocation dynamique de la mémoire que si l'on n'a pas d'autre choix, comme lorsqu'il s'agit de gérer des collections d'objet polymorphes, par exemple...

Il faut savoir que la seule différence qui existe, en C++ entre une classe et une structure tient dans la visibilité par défaut (comprend: en dehors de toute indication contraire dans leur définition)de chacune d'elle:

une structure a une visibilité par défaut publique alors qu'une classe aura une visibilité par défaut privée

A titre d'exemple, une std::string est un typedef spécialisant std::basic_string pour les caractères "ANSI"...

Il ne nous importe pas de savoir s'il s'agit d'une classe ou d'une structure, et, pourtant, il ne viendrait normalement à l'idée de personne de sensé d'utiliser l'allocation dynamique pour déclarer une variable de type std::string :D

Citation:

Dans les méthodes publiques j'aurai rajouté en plus le destructeur :

Pas forcément non plus: le destructeur fournit par défaut par le compilateur est plus qu'amplement suffisant, étant donné qu'il n'y a pas d'allocation dynamique des membres de la classe :D

Pourquoi se faire du mal à réécrire quelque chose qui sera, de toutes façons, rajouté par le compilateur s'il se rend compte que cela manque :question:

Par contre, ce qui me choque bien plus, c'est l'utilisation de tableaux "C style" de taille fixe pour les déclarations de numdeRH et numdeSCD.

Pour être honnête, cela me choque également pour celles de datedeSCD et datedeRH, mais nous dirons que c'est dans une moindre mesure :D

Déjà, je trouve dommage de limiter arbitrairement le nombre d'objets représentés...

Pour l'instant, anthonyplay, tu estimes peut être que tu as de la marge avant d'arriver à devoir gérer plus de 450 éléments, et tu as peut être raison...

En déplaçant les membres de ta classe, tu arrive, peut être, à contourner le problème qui se présente à toi du simple fait que les membres apparaissent en mémoire dans l'ordre de leur déclaration, parce que cela permet d'éviter la perte d'un peu de place ( en fait, du peu de place nécessaire pour faire que cela tienne, effectivement, dans la pile) du fait de l'alignement des données.

Mais tu laisse un problème bien plus important en suspend: la limite arbitrairement posée dans le nombre d'objet que tu peux placer dans ta liste.

Et, bien que je n'ai rien de madame Irma, je vois déjà l'avenir se profiler avec une certitude absolue:

Dans six mois, un an... peut être dix, les 450 éléments ne te suffiront plus: tu en aura besoin de... 451... voire plus...

Déjà, d'ici là, tu sera sans doute tout étonné d'obtenir des résultats aberrants, voire un plantage parce que tu aura oublié cette limite arbitrairement fixée à 450 éléments...

Tu relira alors ton code, en ayant oublié que ton objet tient dans la pile uniquement parce que tu as mieux organisé les membres de la classe et, comme tu verra en première ligne le

Code:

#define NBMAX 450

tu aura naturellement tendance à te dire quelque chose comme

Citation:

Bon, ben, je le passe NBMAX à 900, et je recompile, cela devrait me donner "un peu de champs"

Cela compilera nickel de chez chrome, mais, à l'exécution, tu aura - de nouveau - un dépassement de pile... Que tu ne pourra plus envisager de résoudre par le simple fait de déplacer un membre :P

aussi, la solution que je te proposerais volontiers aura pour but, non seulement de résoudre ton problème de déplacement de pile, mais aussi, de t'éviter des soucis dans le futur: utiliser des collections dynamiques pour gérer les différents membres de ta classe.

Comme tu es parti sur des tableau, je te proposerais donc d'utiliser la classe std::vector, bien qu'il ne soit pas impossible qu'un autre conteneur puisse s'avérer à l'usage plus adapté.

Ta classe prendrait alors la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <vector> // nécessaire pour pouvoir utiliser std::vector #include <string> // nécessaire pour pouvoir utiliser std::string // meme plus besoin de limiter le nombre d'objets :D class Liste { private: std::vector<std::string> numdeRH; std::vector<std::string> numdeSCD; std::vector<int> datedeRH; std::vector<int> datedeSCD; public: /*...*/ };
Maintenant, ce que j'en dis...