Arbres binaires, destructeurs récalcitrant, auto_ptr déroutant les constructeurs.

Hmm bon il y a effectivement des double free, mais je n'ai aucune idée d'où ils viennent car je ne dis jamais moi même de détruire un pointeur...

J'ai fait un petit programme de test avec la version en shared_pointeur, qui plante dès que je cherche à dériver la fonction a->a+3, gdb me dit clairement que j'ai un pointeur qui est détruit une fois par ~noeud et une fois par ~number, et c'est ça qui fait planter le tout....

J'ai téléchargé Boost et commencé à compiler ton projet sous Visual, mais j'ai quelques warnings et une erreur...

Citation:

---

------ Rebuild All started: Project: DvpCom3, Configuration: Debug Win32 ------
Deleting intermediate and output files for project 'DvpCom3', configuration 'Debug|Win32'
Compiling...
cubique.cpp
expo.cpp
loga.cpp
methodes.cpp

• e:\docsetparams\frederic\mes documents\visual studio 2005\projects\testsdiversetdvpcom\dvpcom3\methodes.cpp(72) : warning C4244: 'argument' : conversion from 'unsigned int' to 'float', possible loss of data
• e:\docsetparams\frederic\mes documents\visual studio 2005\projects\testsdiversetdvpcom\dvpcom3\methodes.cpp(104) : error C2668: 'pow' : ambiguous call to overloaded function
  
  • c:\program files\microsoft visual studio 8\vc\include\math.h(489): could be 'double pow(double,int)'
  • c:\program files\microsoft visual studio 8\vc\include\math.h(123): or 'double pow(double,double)'
  
  while trying to match the argument list '(double, unsigned int)'
• e:\docsetparams\frederic\mes documents\visual studio 2005\projects\testsdiversetdvpcom\dvpcom3\methodes.cpp(114) : warning C4244: 'argument' : conversion from 'unsigned int' to 'float', possible loss of data
• e:\docsetparams\frederic\mes documents\visual studio 2005\projects\testsdiversetdvpcom\dvpcom3\methodes.cpp(140) : warning C4244: 'argument' : conversion from 'unsigned int' to 'float', possible loss of data
• e:\docsetparams\frederic\mes documents\visual studio 2005\projects\testsdiversetdvpcom\dvpcom3\methodes.cpp(266) : warning C4244: 'argument' : conversion from 'unsigned int' to 'float', possible loss of data

noeud.cpp
number.cpp
operators.cpp
produit.cpp
puiss.cpp
somme.cpp
symbol.cpp
symlib.cpp
symlibtest.cpp
Generating Code...

• e:\docsetparams\frederic\mes documents\visual studio 2005\projects\testsdiversetdvpcom\dvpcom3\symbol.cpp(105) : warning C4715: 'symbol::Eval' : not all control paths return a value
• e:\docsetparams\frederic\mes documents\visual studio 2005\projects\testsdiversetdvpcom\dvpcom3\noeud.cpp(41) : warning C4715: 'noeud::valeur' : not all control paths return a value

Build Time 0:14
DvpCom3 - 1 error(s), 6 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

---

Sans parler des warnings de conversion de size_t en unsigned...

PS: Ton Test.cpp, c'est du 100% BEURK! :vomi:.
On ne t'a pas appris la compilation séparée, ni à faire un projet ?

En attendant, j'ai vu aussi une autre source de problèmes: Il arrive que tu utilises des pointeurs non-intelligents, et ça fiche le bazar.
En fait, tout truc de ce style cause un double-free:

Code:

---

1 2 3

shared_ptr<UnTruc> p1 = new UnTruc; UnTruc *p2 = p1; shared_ptr<UnTruc> p3 = p2;

---

Pour éviter ce problème, les pointeurs doivent être shared tout du long (ou bien, des pointeurs normaux const puisqu'on ne peut pas créer de shared_ptr non-const à partir d'eux) ou bien tu dois utiliser enable_shared_from_this...

Voici les principaux suspects:

• vector<boost::shared_ptr<noeud> > Grad(noeud* N, vector<string>V);
• Les shared_ptr dans les operator
• Tous les complex utilisent des pointeurs normaux non-const

Je pense que tu aurais beaucoup moins de problèmes si tu savais mettre const où il convient...

Pour le test.cpp, je sais qu'il est moche, c'est juste que pour lier à la main j'avais la flemme.

Mon vrai programme est le symlibtest.cpp qui lui compile avec des fichiers séparés, et le projet a un makefile (je sais pas si visual sait les utiliser, ça me semble probable)

Sinon pour les suspects :

Alors pour le gradient, il peut peut-être poser des soucis, mais pour l'instant je ne l'utilise nulle part.

Pour les complexes, c'est un peu pareil, pas besoin de les utiliser pour que ça plante.

Donc c'est très probablement les opérateurs et/ou les pointeurs normaux qui se baladent.

Par contre je ne sais effectivement pas vraiment utiliser const


Merci bien en tout cas.

--
Z.

Quelques règles de base:

1. Ne jamais construire un shared_ptr<> à partir d'une référence.
2. Ne pas construire non plus un shared_ptr<> à partir d'un pointeur, sauf au moment du new.
3. Toutes les méthodes qui ne modifient pas l'objet doivent être déclarées const.
4. Toutes les références qui ne modifient pas l'objet référencé doivent être déclarées const.
5. Un pointeur dont la durée de vie n'excède pas celle de la fonction et qui ne modifie pas l'objet peut être un pointeur const au lieu d'un shared_ptr<>.

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

// CUneClasse.h class CUneClasse { public: CUneClasse(int val) : m_val(val) { }   //Constructeur de copie qui prend une référence const. CUneClasse(CUneClasse const & src) : m_val(src.m_val) { }   CUneClasse & operator= (CUneClasse const & src) { m_val = src.m_val; }   void SetVal(int val) { m_val = val; }   //Une méthode const: int GetVal(void) const { return m_val; } private: int m_val; };   //L'opérateur d'insertion de flux prend une référence const aussi. inline ostream & operator << (ostream & os, CUneClasse const & obj) { //Seules les fonctions membres const //peuvent être appelées sur un objet const int val = obj.GetVal(); os << val; return os; }

---

Et aussi, j'ai remarqué que certains fichiers d'en-tête (notamment méthodes.h) incluent beaucoup plus de fichiers qu'ils n'en ont besoin. Des inclusions qui seraient beaucoup mieux dans le .cpp, car ça réduit le couplage...

Sans compter qu'on ne doit jamais mettre de using namespace comme ça au niveau global dans un .h...