Plantage en débug et pas en Release (MSVC 2003)

Préférence personnelle : je préfère les algo de la stl aux boucles for.
Et pourquoi ne pas utiliser les std::vector à la place des tableaux classiques (ce qui te soulagerait du problème des allocations).

Ben, parce je me prends plein d'erreur de compilation (je ne saurais pas dire pourquoi, je suppose que c'est un soucis avec l'orde d'inclusion des fichiers MFC/ ou de stdafx.h):

Citation:

---

Envoyé par Microsoft Visual Studio 2003

Compilation...
AfficModele.cpp
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(34) : error C2665: 'operator new'*: aucune des surcharges 5 ne peut convertir le paramètre 1 à partir du type 'char [42]'
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\new.h(100): peut être 'void *operator new(size_t,const std::nothrow_t &) throw()'
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\new.h(108): ou 'void *operator new(size_t,void *)'
lors de la tentative de mise en correspondance de la liste des arguments '(char [42], int)'
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(137)*: voir la référence à l'instanciation du modèle de fonction '_Ty *std::_Allocate<std::allocator<_Ty>::value_type>(size_t,_Ty *)' en cours de compilation
with
[
_Ty=std::allocator<char>::value_type
]
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(136)*: lors de la compilation de la fonction membre du modèle de classe 'std::allocator<_Ty>::pointer std::allocator<_Ty>::allocate(std::allocator<_Ty>::size_type)'
with
[
_Ty=char
]
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstring(30)*: voir la référence à l'instanciation du modèle de classe 'std::allocator<_Ty>' en cours de compilation
with
[
_Ty=char
]
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstring(46)*: voir la référence à l'instanciation du modèle de classe 'std::_String_val<_Ty,_Alloc>' en cours de compilation
with
[
_Ty=char,
_Alloc=std::allocator<char>
]
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(39)*: voir la référence à l'instanciation du modèle de classe 'std::basic_string<_Elem,_Traits,_Ax>' en cours de compilation
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Ax=std::allocator<char>
]

Le journal de génération a été enregistré à l'emplacement "file://d:\developpement\Trajfoot\Debug\BuildLog.htm"
Traj - 1 erreur(s), 0 avertissement(s)


---------------------- Terminé ----------------------

Génération*: 0 a réussi, 1 a échoué, 0 a été ignoré

---

Je soupçonne aussi le sens de la vie, de l'univers et de tout le reste (:lol:).

Comment t'as déclaré?
Ce devrait être quelque chose comme ça :

Code:

---

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

#include <vector> class Reference : public CObject { DECLARE_SERIAL( Reference ) //Données brutes std::vector<int> m_teinte; std::vector<int> m_niveauGris;   //données après traitement std::vector<int> m_teinteEch; std::vector<int> m_niveauGrisEch; //...

---

Ensuite, pour 'allouer' ton vecteur puisque les tailles sont fixes :

Code:

---

1 2 3 4 5

Reference::Reference(void) :m_teinte(TAILLE_TEINTE),m_niveauGris(TAILLE_NIVEAU_GRIS),etc. { initialize(); }

---

Deux autres points qui me reviennent :
1/ On préfère les listes d'initialisations au initialisation dans le constructeur;
2/ Les listes d'initialisations doivent suivre le même ordre que la déclaration des membres dans la classe.

Le point 1 car sinon tu as 1 construction par défaut + 1 affectation. Autant faire la bonne construction dès le début.
Le point 2 car c'est l'ordre que génère le compilateur (peut importe ce que tu auras précisé d'autre). Donc autant être cohérent entre le code écrit et le code généré.

Oui, je l'ai fait automatiquement quand j'ai remanié mon code.
Et oui c'est comme cela que j'ai déclaré mes vecteurs, mais c'est ailleurs que ça me pète à la figure. Vu la complexité du projet je n'ai pas trop envie de jouer au détective, j'ai opté pour faire au plus rapide.

Le problème du try{} catch{} sur des exceptions de type bad_alloc (enfin tout type d'exception quand tu manipules des tableaux dynamique) c'est que le code devient vide très très lourd à gérer, de par sa taille et de par sa redondance (faut gérer en double la libération de la ressource). M'enfin si tu l'as déjà fait et que le projet est gros... pourquoi pas après tout.

Une solution c'est d'utiliser boost::scoped_array pour éviter la lourdeur des try catch.

Il y a aussi le scope_guard d'Alexandrescu qui est très utile (présent dans une des librairies de boost).

Du nouveau en fait je me suis rendu compte que plutôt que de parcourir des adresses mémoires ( for(i = m_tableau; i < m_tableau + max; ++i) *i = 0; ), c'est très mal, et c'est pour ça que le débugueur m'a fait une caca nerveux. Il vaut mieux donc passer par des indices. (for(i = 0; i < lax; ++i) m_tableau[i] = 0; ) ou (for(i = 0; i < lax; ++i) *(m_tableau + i) = 0; ).
Edit : Pour l'inclusion de boost j'aurais bien aimé mais je préfère éviter d'inclure des librairies supplémentaires.
Edit2 : J'ai remis du statique et utilisant l'indexation dur les tableaux et ça s'est remis à planter au même endroit.

Petite question subsidiaire... la taille de la pile se définit en quelle unité? parce que ce n'est pas précisé dans la doc de Visual Studio.

Citation:

---

Envoyé par Floréal

Petite question subsidiaire... la taille de la pile se définit en quelle unité? parce que ce n'est pas précisé dans la doc de Visual Studio.

---

Le MSDN dit :

Citation:

---

This option sets the size of the stack in bytes

---

Au temps pour moi, je suis passé à coté :s

Code:

---

1 2	for(i = 0; i < max; ++i) *(m_tableau + i) = 0;

---

Si tu fais ça, effectivement, ça va mal compiler avec un std::vector :).

La solution de compatibilité vecteur/tableau C :

Code:

---

1 2	for(i = 0; i < max; ++i) m_tableau[i] = 0;

---

La solution C++ :

Code:

---

1 2 3

std::vector<int>::iterator it ; for(it = m_tableau.begin(), it != m_tableau.end(); ++it) *it = 0;

---

Ah ça compile très bien pour la bonne et simple raison que je n'utilise pas de vecteur.
Bien sûr quand j'ai testé l'implantation de vecteur j'ai introduit une nouvelle donnée membre sans remplacer celles qui existaient déjà.
Ceci dit même avec du code propre, quand 'utilisais des tableaux instanciés automatiquement plutôt que dynamiquement, mon programme planté lorsque le débugueur vérifiait la pile (toujours au même endroit qui n'avait rien à voir avec ma classe). Et effectivement ça ne plantait plus en changeant la faille de la pile dans les options de VS, pour moi les origines (successives) du problème ne fait plus de doute.