Utilisation de vector de structure en C++

Salut à tous !!!
Voici le défi :
J'ai une structure de données :

Code:

---

1 2 3 4 5

struct Links { AtomBase &Atome; int Type; };

---

et j'ai une classe qui possède un attribut vector définit comme cela :

Code:

---

vector<Links*> Linked;

---

Dans cette même classe, existe une fonction permettant d'ajouter un nouvel élément Links dans l'attribut vector :

Code:

---

1 2 3 4 5

void Add_Bond(AtomBase i_AtomBonded, int BondType){ Links Link1 = {i_AtomBonded, BondType}; Linked.push_back(&(Link1));   }

---

Ca compile bien, pas de souci :D mais au moment de l'exécution : EXC_BAD_ACCESS !!!! :cry:
J'ai beau chercher, je sais que ca vient de Linked.push_back(&(Link1)); qu'il aime pas mais j'arrive pas à savoir pourquoi ....
Un petit coup de main s'il-vous-plait !! Ca fait 1h30 que je cherche à je commence à désesperer. Merci d'avance !

Salut, et bienvenue sur le forum.

Le fait est que tu te laisse avoir à une erreur classique lorsque l'on manipule des pointeurs: tu prend l'adresse d'une variable locale à ta fonction et qui est donc détruite... lorsque l'on atteint l'accolade fermante:

Code:

---

1 2 3 4 5 6 7 8 9

void Add_Bond(AtomBase i_AtomBonded, int BondType){ // ceci est une variable locale... elle n'existe que pour la // durée de l'exécution de Add_bond Links Link1 = {i_AtomBonded, BondType}; // ca compile, ca?   Linked.push_back(&(Link1)); // tu prend l'adresse mémoire de link1, // mais...   } //link1 est détruit ici, son adresse devient donc invalide

---

Tu dois donc faire en sorte que la variable continue d'exister une fois que l'on a quitté la fonction, et, pour ce faire, il n'y a pas trente six solutions: il faut passer par l'allocation dynamique de la mémoire

Code:

---

1 2 3 4 5 6 7

void Add_Bond(AtomBase i_AtomBonded, int BondType){ Links *Link1 = new Links(/*...*/);   Linked.push_back(Link1); // on ajoute le pointeur   } // on a pris la responsabilité de la gestion de la durée de vie de Link1... // la variable continue donc d'exister...

---

Par contre, cela implique qu'il faut être particulièrement vigilent pour le reste de la gestion de Linked:

1. Si la mémoire allouée à un pointeur contenu dans Linked est libérée, la classe qui utilise Linked doit en être tenue informée et... supprimer le pointeur invalidé
2. Lorsque l'on supprime un élément de Linked, il faut veiller à... libérer la mémoire au plus tard avant de perdre toute référence à l'emplacement mémoire utilisé, sous peine d'observer une fuite mémoire

Merci Koala pour la rapidité de la réponse.
J'ai cru voir la réponse d'un modérateur qui a enlevé son com' y'a 30 secondes disant que toutes utilisations ultérieures seraient faussées. En effet, c'est bien le cas.

J'ai essayé l'utilisation de Links *Link1 = new Links(i_AtomBonded,BondType);
mais ca ne marche pas. Au risque de paraitre faignant et abusif sur ce coup là, un dernier coup de main. Désolé mais je sature completement de ce probleme.

Pour le reste je vais m'arranger dans le destructeur pour bien vérifier que tout est bien désalloué. Merci encore.

Citation:

---

Envoyé par gilims

Merci Koala pour la rapidité de la réponse.
J'ai cru voir la réponse d'un modérateur qui a enlevé son com' y'a 30 secondes disant que toutes utilisations ultérieures seraient faussées. En effet, c'est bien le cas.

---

Effectivement, Bruno a posté une réponse et l'a retirée tout de suite après avoir remarqué (bien que n'y étant pas obligé) que j'avais répondu moins succinctement mais dans le même sens que lui...

Citation:

---

J'ai essayé l'utilisation de Links *Link1 = new Links(i_AtomBonded,BondType);
mais ca ne marche pas. Au risque de paraitre faignant et abusif sur ce coup là, un dernier coup de main. Désolé mais je sature completement de ce probleme.

---

Et pour cause, il n'existe aucun constructeur de Links prenant deux arguments :P

J'avais perdu de vue qu'il s'agissait d'une structure pour laquelle il n'y a aucun constructeur défini par toi, ce qui fait que les Big Four sont de mise.

Essaye peut être avec:

Code:

---

1 2 3

Links *Link1 = new Links; Link1->Atome = i_AtomBonded; Link1->Type = BondType;

---

(au passage, on peut signaler que l'utilisation d'une référence pour le membre Atome de ta structure risque très fortement de poser des problèmes par la suite ;))

Ok j'ai réussi à faire le constructeur de la structure

Code:

---

Links::Links(AtomBase Atome1,int Type1) { Atome=&Atome1; Type= Type1;}

---

J'ai un peu modifier la structure

Code:

---

1 2 3 4 5 6 7 8

struct Links { Links(AtomBase Atome1,int Type1); public: AtomBase *Atome; int Type;   };

---

Et le code d'ajout :

Code:

---

1 2 3 4 5 6 7

void AtomBase::Add_Bond(AtomBase i_AtomBonded, int BondType){ Links *Link1 = new Links(i_AtomBonded,BondType);   //(*Link1).Atome = i_AtomBonded; Linked.push_back(Link1);   }

---

Cependant, on en reviens à ce que Bruno et toi disiez, l'accès aux données pose un problème :

Code:

---

cout << Linked[0].Type << endl;

---

Ca continue à me renvoyer un EXC_BAS_ACCESS.

Et là on parle même pas de l'élément Atome, mais juste d'un integer. :aie:
Je suis désespéré .... :calim2: ^^

Pourquoi tu utilises des pointeurs si tu ne sais pas t'en servir?

Est-ce qu'il y en a besoin?

Est-ce que tu as vraiment besoin d'une référence/pointeur sur AtomBase? Dans ce cas là, pourquoi tu en passes un paramètre par copie lors de la construction?

voilà mon conseil: commence simple et réfléchis à ce que tu veux faire.

La solution simple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

struct Link { Link( const AtomBase & atome, int type ) : atome_( atome), type_( type ) {}   AtomBase atome_; int type_; };   std::vector<Link> links;   void add_bond( const AtomBase & atomBonded, int bondType) { links.push_back( Link( atomBonded, bondType ) ); }

---

Bon par contre, le C++, ce n'est pas du C, ce n'est pas du Java, va falloir revoir quelques bases (la FAQ C++ developpez.com?) :)

Au moins c'est de la réponse !!! :oops:

Citation:

---

Pourquoi tu utilises des pointeurs si tu ne sais pas t'en servir?

---

Pas trop le choix pour bien gêrer le programme. Je sais que je déteste ca et que je comprends pas forcément mais c'est en forgeant qu'on devient forgeron.

Citation:

---

Est-ce qu'il y en a besoin?
Est-ce que tu as vraiment besoin d'une référence/pointeur sur AtomBase?

---

Définitivement oui. 2 atomes sont reliés par 1 Bond (liaison). Si je n'utilise pas des références/pointeurs, je perds sur le controle sur toute possibilité de modification.

Citation:

---

Dans ce cas là, pourquoi tu en passes un paramètre par copie lors de la construction?

---

C'est bien ce que je me disais, mais j'avoue je n'étais pas sur.

Citation:

---

Bon par contre, le C++, ce n'est pas du C, ce n'est pas du Java,

---

Juste pour être certain, on a le droit d'utiliser des structures de données en C++, ca je pense. Mais que vaut-il mieux faire pour ce cas là ??

Les pointeurs ne sont pas une fatalité, tu pourrais très bien avoir un id pour chaque Atom et un Link qui contient l'id de deux Atom par exemple. Comme dans une base de données relationelle.

Bonjour,

Citation:

---

Envoyé par gilims

Ok j'ai réussi à faire le constructeur de la structure

Code:

---

Links::Links(AtomBase Atome1,int Type1) { Atome=&Atome1; Type= Type1;}

---

---

vous avez encore fait la même erreur : vous mémorisez l'adresse d'une variable locale, ici Atome1 :fessee:

Citation:

---

Envoyé par gilims

Définitivement oui. 2 atomes sont reliés par 1 Bond (liaison). Si je n'utilise pas des références/pointeurs, je perds sur le controle sur toute possibilité de modification.

---

A partir du moment ou un atome peut être relié à plusieurs autres il faut bien-sûr que vous passiez par des pointeurs, ni par valeur, ni par référence non plus.

cela veut dire que le contructeur de Link doit recevoir des AtomBase *, surtout pas de paramètre de type AtomBase &, et pas d'attribut AtomBase & atomxx; mais AtomBase * atomxx;

Citation:

---

Envoyé par nikko34

Les pointeurs ne sont pas une fatalité, tu pourrais très bien avoir un id pour chaque Atom et un Link qui contient l'id de deux Atom par exemple. Comme dans une base de données relationelle.

---

non, inutile de faire compliqué, de plus cela ne résout rien car vous vous retrouverez par exemple avec un id correspondant à un élément qui n'existe plus par exemple. Ici il faut utiliser des pointeurs.

Citation:

---

Dans ton cas, que tu utilises des pointeurs ou des références, si ton vector d'atom change, il va falloir mettrre à jour ton vector de links avant de supprimer les atoms.

---

il faut effectivement décider de "qui sait quoi" c'est à dire "qui référence qui". Par exemple est-ce qu'un atome à besoin de connaitre ses liaisons avec les autres ?
il n'est pas possible de répondre à cette question dans l'absolu, il faut savoir ce que vous comptez faire avec vos atomes et liaisons

Citation:

---

La version avec des références par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

struct Link { Link( AtomBase & atom1, AtomBase & atom2 int type ) : atom1_( atom1), atom2_( atom2), type_( type ) {}   AtomBase & atom1; AtomBase & atom2; int type_; }; ...

---

---

cette solution est catastrophique :aie:

une référence est un pointeur 'déguisé', dans les deux cas il s'agit de l'adresse de l'objet pointé, une référence c'est juste du sucre syntaxique permettant une utilisation plus souple et automatisée qu'un simple pointeur, mais à la base il n'y a pas de différence.

ah oui mince je suis bête t'as raison le std::vector va tout changer à la moindre manip'. Yavait donc bien une raison pour laquelle je ne faisais pas ça :) Je vais arrêter les exemples mal reveillé :)

Donc oui des pointeurs.

Ok bon, là j'avoue, je capitule.... :aie:
Récapitulons ^^.
On a donc la structure Links avec son constructeur :

Code:

---

1 2 3 4 5 6

struct Links { Links( AtomBase & atom1, int type ) : Atome( atom1), Type( type ){ } AtomBase & Atome; int Type; };

---

Et la fonction Add_bond :

Code:

---

1 2 3 4 5 6 7

void AtomBase::Add_Bond(AtomBase *i_AtomBonded, int BondType){ Links *p; p = new Links( *i_AtomBonded, BondType ); Linked.push_back( p ); cout << Linked.back()->Type << endl;   }

---

Alors là, le probleme qui se pose, et que j'ai bien compris maintenant, c'est que je crée un pointeur Links que j'ajoute à mon vecteur Linked. Le cout << Linked.back()->Type << endl; m'affichera bien la valeur voulue, mais dès que je sors de la fonction ... pouf !!! envolé. Ce qui est normale vu que c'est une variable localement crée. Comment faire pour qu'elle reste en l'état ???!!! Je commence à comprendre le principe :ccool:, manque encore ce point à régler... ou alors j'ai tout faux

:cry: pourquoi continuez-vous à utiliser des références dans Links ?:calim2:

renommez aussi Links en Link puisque chaque instance de la classe ne concerne qu'un lien

vous avez modifié Link(s) qui ne mémorise plus qu'un des atomes relié, est-ce Linked est un attribut de AtomBase ?

Bon c'est officiel j'y comprends plus rien !!! :aie:
On va essayer de recadrer un peu le probleme. J'ai donc 1 atome, représenté par la classe AtomeBase. Dans cette classe se trouve, l'attribut Linked définit de la facon suivante : vector<Links*> Linked;
Puisqu'un atome est relié à un autre atome par une liaison, cette liaison est enregistré avec son type et avec la référence à l'atome rélié, ce qui permettra par la suite de pouvoir accéder facilement aux informations de l'atome relié.
Bon j'avoue j'ai fait des modifs qui doivent être encore pire, mais au point où j'en suis je teste tout :
Voici la structure Links (que je pourrais très bien nommé Link)

Code:

---

1 2 3 4 5 6

struct Links { Links( AtomBase * atom1, int type ): Atome( atom1), Type( type ){ } AtomBase * Atome; int Type; };

---

Et voici le code d'ajout d'un nouvel élément Links dans le vector Linked.

Code:

---

1 2 3 4 5 6 7 8

void AtomBase::Add_Bond(AtomBase *i_AtomBonded, int BondType){ //Links *p; //p = new Links( *i_AtomBonded, BondType ); Linked.push_back( Links( i_AtomBonded, BondType ) ); cout << Linked.back().Type << endl;   }

---

Pourquoi ca marche pas !!!!:furax:

la définition de Add_Bond suppose que l'on a vector<Links> Linked et non pas vector<Links*> Linked

et en fait vector<Links> Linked est la bonne solution à partir du moment où un Links n'est pas référencé par plusieurs éléments (ce qui serait le cas si deux atomes reliés mémorisait chacun le lien les reliant)

vous n'avez pas répondu à ma question est-ce Linked est un attribut de AtomBase, si ce n'est pas le cas alors bien-sûr votre système ne marche pas ;)

P.S. mauvaise idée d'utiliser une majuscule en premier caractère d'un attribut d'instance, utilisez cela plutôt pour les attributs de classe ou les variables globales (C) ;)

Merci d'être aussi persévérant, c'est sympa ^^.

Citation:

---

et en fait vector<Links> Linked est la bonne solution à partir du moment où un Links n'est pas référencé par plusieurs éléments (ce qui serait le cas si deux atomes reliés mémorisait chacun le lien les reliant)

---

Links n'est pas référencé par plusieurs éléments. En effet dans ma tete, si on a la liaison A-B, on aurait alors dans la classe AtomBase A, le Linked qui contiendrait de facon schématique A->( adresse de B, type de liaison) et B-> (adresse de A, type de liaison). Les 2 linked formait serait donc différent.

Citation:

---

vous n'avez pas répondu à ma question est-ce Linked est un attribut de AtomBase, si ce n'est pas le cas alors bien-sûr votre système ne marche pas

---

Oui, Linked est un attribut d'AtomBase. Mais dans ce cas pourquoi le systeme ne marcherait pas ?


Pour les majuscules, je tacherais d'y penser à l'avenir. Force de l'habitude.:D

Citation:

---

Envoyé par gilims

Oui, Linked est un attribut d'AtomBase. Mais dans ce cas pourquoi le systeme ne marcherait pas ?

---

c'est l'inverse, si Linked n'avait pas été un attribut d'instance d'AtomBase alors un atom ne saurait pas à qui il est relié

puis-je savoir pourquoi vous aviez changé Links pour qu'il ne référence plus les deux atomes qu'il relie ?

Citation:

---

c'est l'inverse, si Linked n'avait pas été un attribut d'instance d'AtomBase alors un atom ne saurait pas à qui il est relié

---

Au moins on est d'accord sur un point !!!:D

Citation:

---

puis-je savoir pourquoi vous aviez changé Links pour qu'il ne référence plus les deux atomes qu'il relie ?

---

Tout simplement parce que je suis perdu. Ce fichu problème d'adresse m'a enlevé toute optique logique et correcte du point de vue fonctionnel de l'histoire.

Ne vous embêtez pas Bruno_pages, je suis en train de reconstruire mon fichier, et avec les informations données ici, j'y verrais surement plus clair. Je posterais la réponse dès que je l'ai trouvé. Merci pour tout ;)

:mrgreen:

ce qui me gène dans la solution actuelle c'est que pour relier deux atomes vous devez creer deux liens, et bien-sûr ces deux liens doivent avoir le même type.

l'autre solution c'est donc quelque chose comme cela :

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

#include <list> using namespace std;   class Atom;   class Link { public: Link(Atom * a1, Atom * a2, int type); ~Link();   private: Atom * _a1; Atom * _a2; int _type; // rien de mieux qu'un int ? };   class Atom { public: Atom() {} ~Atom(); void link(Link *); void unlink(Link *);   private: list<Link *> _links; };   Link::Link(Atom * a1, Atom * a2, int type) : _a1(a1), _a2(a2), _type(type) { a1->link(this); a2->link(this); }   Link::~Link() { _a1->unlink(this); _a2->unlink(this); }   Atom::~Atom() { list<Link *>::iterator it;   while (! _links.empty()) delete _links.front(); }   void Atom::link(Link * l) { _links.push_back(l); }   void Atom::unlink(Link * l) { _links.remove(l); }

---

ce qui précède n'est pas fini et comporte des lacunes graves, si cela vous intéresse de les chercher ;)

Je suis d'accord sur la redondance des données pour Type. Hélàs, celle-ci est nécessaire pour assurer la cohérence des calculs futurs.

En tout cas, après avoir recommencé à zéro, j'ai finalement réussi.
En relisant, j'ai remarqué que j'avais pas réussi à mettre de minuscules aux attributs, les habitudes ont la vie dure ... :?

Bref, je vous soumets mon code pour critique :
Structure Link:

Citation:

---

struct Link
{
AtomBase *Atom;
unsigned int Type;
Link(AtomBase *_Atom, unsigned int _Type): Atom(_Atom),Type(_Type) {};
};

---

La classe AtomBase:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class AtomBase { private: int Num; string Nom; vector<Link> Linker; public: AtomBase(); void AddLink(Link *_Linker);   };

---

La fonction AddLink() :

Code:

---

1 2 3 4 5

void AtomBase::AddLink(Link *_Linker) { Linker.push_back(*_Linker); }

---

Et la fonction appelante :

Code:

---

1 2 3 4 5 6 7 8 9

void MolBase::Add(BondBase _Bond) { Bonds.push_back(_Bond); Link *p = new Link(&Atoms.at(_Bond.Get_Atom1()), _Bond.Get_BondType()); Atoms.at(_Bond.Get_Atom2()).AddLink(p); Link *p2 = new Link(&Atoms.at(_Bond.Get_Atom2()), _Bond.Get_BondType()); Atoms.at(_Bond.Get_Atom1()).AddLink(p2); }

---

Et la classe BondBase :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class BondBase {   private: unsigned int Type; unsigned int Atom1; unsigned int Atom2; public: BondBase(unsigned int _Type,int _Atom1,int _Atom2);   int Get_Atom1(); int Get_Atom2(); int Get_BondType(); void __ToString(); };

---

Mon idée éventuelle pour éviter la rédondance serait d'utiliser l'adresse de Type contenu dans BondBase, comme ca, on n'aurais qu'une seule fois le Type de liaison et il serait identique pour tous. Mais j'ai du mal à récupérer l'adresse de cet attributs 8O
Sinon, place aux critiques !!! :mrgreen:

Citation:

---

Envoyé par gilims

Sinon, place aux critiques !!! :mrgreen:

---

d'abord c'est franchement bien compliqué pour pas grand chose, il suffit de comparer la taille du code de ma proposition et la votre pour s'en rendre compte immédiatement.

sinon le manque le plus flagrant dans votre proposition c'est que la destruction d'un atome ou d'une liaison laissera les objets encore existants dans un état incohérent car pointant vers les éléments détruits :aie:

si vous regardez ma proposition vous verrez que la destruction d'un atome détruit proprement ses éventuelles liaisons. De même la destruction d'une liaison provoque la mise à jour des deux atomes qu'elle reliait. Bref ca marche ... si ce n'est les lacunes dont j'ai parlé histoire de vous faire réfléchir ;)

J'avais mal compris le point de vue que vous m'aviez proposé. désolé.:oops:
Au moins, refaire le code avec ma version m'a permis de mieux cibler mon erreur et de la corriger. Maintenant, je vais tester un peu votre idée. :ccool:

Dites moi, vous auriez pas bosser dans la chimie un peu ??? :D

Bien bien bien. J'adore ce point de vue !!! merci !!!
Je l'ai un peu modifié de façon à mieux l'adapter au sujet. Il n'est pas nécessaire de créer la classe Link comme vous le proposiez, car celle-ci s'avère être la classe BondBase déjà existante. Je n'avais pas fait la connexion comme vous le proposiez, et je regrette amèrement de ne pas y avoir pensé plus tôt !!!

Donc j'ai repris votre idée de list de BondBase* cette fois.
Voici la sortie du programme :

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 26 27

-----------ATOME---------- Atome 0 : C1 Adresse : 0x100100110 Nbr liaison : 1 -----------ATOME---------- Atome 1 : H2 Adresse : 0x100100160 Nbr liaison : 1 --------Liaison------- Adresse : 0x1001001b0 Entre atome 0 et 1. Liaison de type 1 Adresse de 0 : 0x100100110 Adresse de 1 : 0x100100160 ----------------------       Suppression de la liaison dont l'adresse est : 0x1001001b0 -----------ATOME---------- Atome 0 : C1 Adresse : 0x100100110 Nbr liaison : 1 -----------ATOME---------- Atome 1 : H2 Adresse : 0x100100160 Nbr liaison : 1

---

Comme on peux le constater les relations atomes/liaison sont bien réalisés.
Le probleme qui se pose maintenant, je dirais le tout dernier avec une certaine confiance (j'epère 8-)) c'est que le unlink que vous proposiez n'est pas réalisé. Et pour cause, je n'arrive pas à le programmer, le compilateur me le refuse.

Voici BondBase.h :

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 26 27 28 29 30

class AtomBase;   class BondBase: public Coords {   private: unsigned int Type; unsigned int NAtom1; // N° de l'atome 1, nécessaire unsigned int NAtom2;// N° de l'atome 2, nécessaire AtomBase* Atom1; // adresse de l'atome 1 AtomBase* Atom2; // adresse de l'atome 2 public: BondBase(unsigned int _Type,int _Atom1,int _Atom2); ~BondBase(); int Get_Atom1(); int Get_Atom2(); int Get_BondType();   void Set_AddrAtom1(AtomBase* At1); void Set_AddrAtom2(AtomBase* At2); AtomBase* Get_AddrAtom1(); AtomBase* Get_AddrAtom2();       void Set_BondType(unsigned int _Type);   void __ToString(); };

---

et voici le code du destructeur :

Code:

---

1 2 3 4 5

BondBase::~BondBase() { cout << "Suppr bond :" <<this << endl; //cout << *Atom1->unlink() << endl; }

---

Le compilateur sort pour la ligne *Atom1->unlink() : invalid use of incomplete type 'stuct AtomBase'. Imcompréhensible vu que c'est une classe.
Je pense que le problème vient du fait que j'ai mis un prototype de la classe AtomBase dans BondBase.h. Je sais pas pourquoi il me casse les pieds avec, sachant que de toute façon, AtomBase utilise BondBase et réciproquement.

Ca c'est AtomBase

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

AtomBase::~AtomBase() { list<BondBase *>::iterator it; //cout << Nom <<Num << " size : " <<linker.size()<< endl; for (int Ivar1 = 0; Ivar1 < linker.size(); Ivar1++) { if (!linker.empty()){ linker.pop_back(); } }     }   void AtomBase::link(BondBase *l) { linker.push_back(l); } void AtomBase::unlink(BondBase *l) {cout << "removing link"; linker.remove(l); }

---

Dernier coup de main .... please.
En tout cas, je sais que je me répète, mais merci encore, j'ai appris bien plus sur les pointeurs, les list, et les relations en 3 jours qu'en 3 mois. :zoubi:

Bonjour,

cout << *Atom1->unlink() est triplement erroné :

• AtomBase::unlink prend un argument (un BondBase *)
• AtomBase::unlink ne retourne rien (void), donc * est invalide car on ne déréférence pas void
• et la chose ne peut être donnée à cout <<

la définition de ~AtomBase() n'est pas valide :

• lorsqu'un AtomBase est détruit il faut détruire les BondBase qui le relie
• it ne sert à rien
• le test de sortie sur IVar1 est invalide car linker.size() rend une valeur qui est décrémentée à chaque tours mais en même temps vous comparez cette taille avec IVar1 qui lui est incrémentez à chaque fois => la liste de sera pas vidée
• le fait que la boucle contienne if (!linker.empty()) est également incohérent puisque le test de sortie de boucle doit être ce qui décide qu'il faut continuer ou non

pourquoi ne pas avoir suivi ma définition de ~Atom ?

AtomBase::Type est encore un int, vous n'avez rien de plus parlant comme une énumération par exemple ?

Get_AddrAtom1/2 et Set_AddrAtom1/2 c'est vraiment pas de beaux noms d'opération à cause d'Addr.

Que représentent NAtom1/2 ? cela ne peut-il pas être défini au niveau de AtomBase ?

Les noms en xxBase c'est pas terrible non plus, je suppose que ce sont des interfaces héritées par d'autre classes, vous pouvez donnez des exemple de ces autres classes ?

désolé de retard... coincé par le boulot.

Citation:

---

cout << *Atom1->unlink() est triplement erroné :

* AtomBase::unlink prend un argument (un BondBase *)
* AtomBase::unlink ne retourne rien (void), donc * est invalide car on ne déréférence pas void
* et la chose ne peut être donnée à cout <<

---

Oui, c'est juste que j'avais pas vérifié ce que j'avais copié. J'avais fait des suppressions entre 2 lignes et elles se sont concaténer.

Citation:

---

AtomBase::Type est encore un int, vous n'avez rien de plus parlant comme une énumération par exemple ?

---

Si Si, pourquoi pas...

Citation:

---

Que représentent NAtom1/2 ? cela ne peut-il pas être défini au niveau de AtomBase ?

---

En effet, ils sont définis au niveau de AtomBase. Il faut plutot que je fasse une petite fonction qui pointent vers NAtom d'AtomBase.

Citation:

---

Les noms en xxBase c'est pas terrible non plus, je suppose que ce sont des interfaces héritées par d'autre classes, vous pouvez donnez des exemple de ces autres classes ?

---

Elles sont censées être hérité par d'autres classes. Mais je les ai pas commencé. Ca sert à rien de commencer les étages d'une maison sans les fondations.

--------------------------------------------------------
J'ai retravaillé mon code encore et encore et encore. Je l'ai recommencé 4 fois en tout et j'ai toujours les mêmes erreurs de M*****.

MolBase.h :

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 26 27

#ifndef DefMolBase #define DefMolBase   #include <vector> #include "BondBase.h"   using namespace std;   class MolBase { private :     //vector<BondBase> Bonds; public : vector<AtomBase*>::iterator Atome; //vector<AtomBase> Atoms; vector<AtomBase*> Atoms; vector<BondBase*> Bonds; MolBase(); ~MolBase(); bool Atom_Empty(); void List_AddrAtoms(); void Add_Atom(AtomBase* _Atom1); };   #endif

---

MolBase.cpp :

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

#include "MolBase.h" #include <iostream> using namespace std; MolBase::MolBase() {};   bool MolBase::Atom_Empty() { return Atoms.empty();}   MolBase::~MolBase() { //AtomBase* ptr; List_AddrAtoms(); while (!Atom_Empty()) { delete Atoms.back(); Atoms.pop_back();   //cout << ptr << " " << ptr->Num<< endl; List_AddrAtoms(); } }   void MolBase::Add_Atom(AtomBase *_Atome) { cout << endl<< "Add Atom : " << _Atome<<endl; Atoms.push_back(_Atome); cout << "Atoms.push_back : " <<Atoms.back() << endl; cout << "Nombre d'element: "<< Atoms.size() << endl; cout << "Mole->Atomes vide : " << Atom_Empty()<<endl; }     void MolBase::List_AddrAtoms() {     cout << "Liste adresse atome contains:"; for ( Atome=Atoms.begin() ; Atome < Atoms.end(); Atome++ ) cout << " " << *Atome ;   cout << endl;   }

---

BondBase.h:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#ifndef DefBondBase #define DefBondBase   #include "AtomBase.h"   using namespace std;   class BondBase { private: AtomBase* Atom1; AtomBase* Atom2; public: BondBase();   };   #endif

---

AtomBase.cpp :

Code:

---

1 2 3 4 5 6 7

#include "AtomBase.h" #include <iostream> using namespace std;   AtomBase::AtomBase(int _Num):Num(_Num) {}; AtomBase::~AtomBase() {cout << "Suppr " << endl;};

---

AtomBase.h:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#ifndef DefAtomBase #define DefAtomBase   #include <vector>   using namespace std;   class BondBase;   class AtomBase { private:   //vector <BondBase*> Link; public: int Num;   AtomBase(int _Num); ~AtomBase(); };     #endif

---

Main.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#include <iostream> #include "MolBase.h" int main (int argc, char * const argv[]) { AtomBase Atom1(1); AtomBase Atom2(2); MolBase Mole; cout << "------------ ATOME 1 ----------- " <<endl; cout << "Adresse creation : " << &Atom1<<endl; cout << "Mole-> Atomes : " << Mole.Atom_Empty()<<endl; Mole.Add_Atom(&Atom1); Mole.Add_Atom(&Atom2); //Mole.List_AddrAtoms(); std::cout << "Hello, World!\n";   return 0; }

---

Le compilateur me sort une erreur du type : "freeing a pointer we didn't allocate that was not claimed by any registered zone". Tout ca pour dire que la commande delete Atoms.back(); dans MolBase.cpp ne supprime pas l'AtomBase alors qu'il est censé le faire. J'ai pourtant suivit toutes vos recommandations, et pas moyen de réussir. Comme je pense que le problème est identique pour l'histoire Liaison-Atome, je pense que régler l'un va me permettre de régler l'autre. J'avoue sérieusement que ca m'énerve de pas comprendre cette histoire ...:?

Bonjour,

ce qui arrive est normal, en sortie le destructeur de MolBase est appelé pour Mole, et celui-ci fait delete Atoms.back() c'est à dire sur Atom1 et Atom2 alors que ceux-ci sont en pile :aie:

votre programme suppose que les AtomBase sont alloués dans le tas, pas placés en pile, le fait d'écrire Mole.Add_Atom(&Atom1) avec le '&' aurait du attirer votre attention

pour info voici que ce dit valgrind :

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

bruno@linux-ysqo:/tmp> valgrind ./a.out ==4557== Memcheck, a memory error detector. ==4557== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==4557== Using LibVEX rev 1732, a library for dynamic binary translation. ==4557== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==4557== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==4557== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==4557== For more details, rerun with: -v ==4557== ------------ ATOME 1 ----------- Adresse creation : 0xbefede9c Mole-> Atomes : 1 Add Atom : 0xbefede9c Atoms.push_back : 0xbefede9c Nombre d'element: 1 Mole->Atomes vide : 0 Add Atom : 0xbefede98 Atoms.push_back : 0xbefede98 Nombre d'element: 2 Mole->Atomes vide : 0 Hello, World! Liste adresse atome contains: 0xbefede9c 0xbefede98 Suppr ==4557== Invalid free() / delete / delete[] ==4557== at 0x4022156: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==4557== by 0x8048E42: MolBase::~MolBase() (MolBase.cpp:14) ==4557== by 0x804A101: main (Main.cpp:15) ==4557== Address 0xBEFEDE98 is on thread 1's stack Liste adresse atome contains: 0xbefede9c Suppr Liste adresse atome contains: Suppr Suppr ==4557== ==4557== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 3 from 1) ==4557== malloc/free: in use at exit: 0 bytes in 0 blocks. ==4557== malloc/free: 2 allocs, 4 frees, 12 bytes allocated. ==4557== For counts of detected errors, rerun with: -v ==4557== All heap blocks were freed -- no leaks are possible.

---

il suffit donc de changer votre main en :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int main (int argc, char * const argv[]) { AtomBase * Atom1 = new AtomBase(1); AtomBase * Atom2 = new AtomBase(2); MolBase Mole; cout << "------------ ATOME 1 ----------- " <<endl; cout << "Adresse creation : " << Atom1<<endl; cout << "Mole-> Atomes : " << Mole.Atom_Empty()<<endl; Mole.Add_Atom(Atom1); Mole.Add_Atom(Atom2); //Mole.List_AddrAtoms(); std::cout << "Hello, World!\n"; return 0; }

---

Eh ben, j'aurais jamais cru m'en sortir de ce problème. Tout marche, sans aucune fuite mémoire ... ou presque. J'ai juste un détail qui va paraître nul par rapport à tout ce qu'on a dit précédemment mais bon. J'ai réussi à bien faire les liens entre atomes->liaisons et liaisons->atomes. J'arrive à lire les données des atomes dans la classe liaison, mais pas l'inverse.

Tout ce que trouve mon compilateur à dire, avec cet AtomBase.h :

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

class BondBase;   class AtomBase { private: unsigned int Num; list <BondBase*> Links; public: void __ToString(); ~AtomBase();   AtomBase(int _Num);   unsigned int Get_Num();   void Set_Num(unsigned int _Num);   list<BondBase*>::iterator Link; void Add_link(BondBase* _Link); void Unlink(BondBase* _Link); bool Has_Link();     };

---

c'est : Forward declaration of 'struct BondBase' ...
Après ca, je mets en résolu.:ccool:

Dans AtomBase.h on déclare que BondBase est une classe (class BondBase), c'est une forward declaration.

Donc un fichier qui inclut AtomBase.h sait juste que BondBase est une classe, rien de plus, mais si le code utilise 'vraiment' la classe alors il y a un problème car sa définition est inconnue et le compilateur râle

il suffit donc de savoir quel est le .cpp qui ne se compile pas et d'ajouter dans celui-ci un #include "BondBase"

Citation:

---

aucune fuite mémoire ... ou presque

---

:rouleau: il faut apprendre à corriger cela, c'est valgrind qui les signale ?

Citation:

---

:rouleau: il faut apprendre à corriger cela, c'est valgrind qui les signale ?

---

:mouarf: C'était juste pour le plaisir. ;)
En réalité j'en ai hélàs absolument aucune idée. valgrind ne marche pas avec mon système (Mac 10.6). J'utilise XCode pour trouver les fuites de mémoires, mais il avait pas réussi à me dire ce que j'attendais sur le problème précédent (problème que vous avez résolu avec Valgrind). Je vais continuer à chercher un programme équivalent qui fonctionne avec des programmes 64 bits.

Pour le petit probleme de BondBase.h c'est réglé, il était manquant dans AtomBase.cpp.

En tout cas, un grand merci à vous pour votre aide et vos petits conseils glissés par ci et là. :ccool: