Discussion :

[Dodidou]

Bonjour à tous !

La STL me pose quelques soucis et j'ai dans l'espoir que l'un d'entre vous puisse m'apporter un élément de réponse !
Je travail avec la version Visual C++ 2008 Express.

Mon problème se résout à ces quelques lignes de codes :

Code :

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

1
2
3
4
5
6
7
8
9
 
	std::list<int*> l1; 
	l1.push_back(new int(5)); 
 
	std::list <double*> l2 ;
	l2.push_back(new double (5));
 
	std::list <float*> l3;
	l3.push_back(new float (5));

Ce bout de code est placé dans une fonction d'une librairie externe.
Lorsque je l'appelle à partir de mon premier projet (une Application Win32 Console) tout se déroule pour le mieux (ce qui me parait logique puisque le bout de code semble cohérent).

Je tente alors de l'utiliser dans mon deuxième projet (un projet utilisant le moteur OGRE3D), et j'obtiens alors l'erreur suivante "list insert iterator outside range" à la dernière ligne ("l3.push_back(new float (5));").

Avez-vous une idée de quel type d'erreur il s'agit?
existe t - il des propriétés de projet qui pourraient corrompre l'utilisation de la STL ? ...

bref... je suis preneur de toutes suggestions !

[Klaim]

Clairement le problème viens de l'environnement du projet, donc de code source autre que celui ci.

Il va falloir isoler le code voir si c'est bien quelque chose avant ce code ci qui (apparamment) corrompt les données.

[koala01]

Salut, et bienvenue sur le forum.

Avant de penser à te répondre, j'aurais volontiers une question (surement idiote) à te poser, mais...

Pourquoi utiliser des pointeurs et l'allocation dynamique de la mémoire dans la collection, alors que de objets "normaux" iraient tout aussi bien

En effet, les différentes collections de la STL souffrent d'un désagrément majeur lorsqu'elles contiennent des pointeurs: elle ne libèrent pas la mémoire allouée aux dits pointeurs lors de leur destruction.

Si tu n'y prend pas garde, tu risque donc de te trouver très facilement en présence de fuites mémoires qui finiront tôt ou tard par s'avérer fatales pour l'application, voire, pour le système tout entier...

De plus, l'utilisation de pointeurs ne se justifie généralement que dans deux cas, qui ne semblent pas être présents dans le code que tu présente:

Soit il s'agit de liens vers des objets dont la durée de vie est gérée "par ailleurs" (par une autre collection ), soit tu te trouve dans un contexte d'héritage et de polymorphisme, et tu décide de créer une collection de pointeurs sur des objets qui passent pour être du type de base, mais tu y place... des objets du type dérivés.

[Arzar]

existe t - il des propriétés de projet qui pourraient corrompre l'utilisation de la STL ? ...

Oui, typiquement, avec visual studio il faut bien faire attention à ce que toutes les dlls utilisées et tous les projets d'une même solution soient compilés avec les mêmes options de debug/check de la STL: _HAS_ITERATOR_DEBUGGING et _SECURE_SCL. Sinon, ça peut mener à des bugs extremement bizarres et difficiles à debugger. (par exemple, les itérateurs n'ont pas la même taille si _SECURE_SCL vaut zero ou un... ça peut mettre un sacré boxon)

Les projets par défaut sous vs2005/2008 activent les checks d'itérateur, même en release, alors qu'un projet Ogre3D désactive probablement tout, pour obtenir les meilleures performances possibles. Il faudrait vérifier.

[Mac LAK]

Voir aussi cette discussion : si tu as des warnings 4251 (level 4 requis) en compilant ton code, alors les résoudre devrait lever ton crash à l'exécution.

[Dodidou]

Merci à tout le monde pour l'aide que vous avez apportée !
Grâce à vous j'ai enfin résolu mon problème.

J'ai commencé par suivre les conseils de Klaim, en essayant d'isoler au mieux le code source bloquant.
J'ai commenté la plupart de mon projet et j'ai enlevé toutes les librairies utilisées.
Au départ, lorsque j'appelle ma fonction en début de programme, mon application génère la fameuse erreur "list insert iterator outside range". Après avoir tout commenté, la fonction ne pose plus aucun problème : étrange non ?!!
Petit à petit j'ai ensuite rajouté et décommenté le code. Bien que l’exercice soit long et pénible, j’en suis finalement arrivé au stade où j’ai identifié la fonction faisant planter le bout de code. Ce qui devient embêtant c’est que cette fonction appartient à la librairie OpenCV (cvSetIdentity). Casse-tête : comment la jolie fonction OpenCV peut – elle corrompre la totalité de mon projet ? D’autant plus que la fonction n’est pas du tout appelée, mais simplement compilée dans le programme !

Après avoir maudit Visual C++ sur plusieurs générations, je retourne sur le site de developpez.com.
Pour répondre à koala01, je n’ai pas choisit d’utiliser l’allocation dynamique dans ma list. Un collègue de travail a écris cette librairie et en théorie je n’ai pas à y retoucher. De même, merci Mac LAK, mais je n’avais pas ce genre de warning. Mais encore une fois : merci bien à tout deux !

Je me suis alors attardé sur le post d’Arzar. Effectivement mes deux projets n’avaient pas la même valeur pour _HAS_ITERATOR_DEBUGGING : mon projet Ogre étant compilé avec l’option NDEBUG !
Je change alors le NDEBUG en _DEBUG ! Saint-Graal de la programmation : mon bout de code fonctionne parfaitement, même avec l’appelle à la fonction OpenCV ! Je décommente la totalité, je test : tout fonctionne…

Moralité… je ne comprends toujours pas ce qu’il s’est passé ! Je pensais qu’on pouvait sans problème utiliser une librairie de Release dans un projet Debug, et inversement.

Pour une fois qu’un lundi matin commence bien ….
Au risque de me répéter : Merci pour votre aide !

[Mac LAK]

Moralité… je ne comprends toujours pas ce qu’il s’est passé ! Je pensais qu’on pouvait sans problème utiliser une librairie de Release dans un projet Debug, et inversement.

Houlà, non, loin de là même !

Exemple typique, l'allocation mémoire : Visual introduit du code spécifique lors du malloc / free pour vérifier si tu n'as pas débordé, et également initialise de façon particulière les variables locales en mode Debug.

Le cas classique, c'est d'allouer la mémoire en Release, et de la libérer en Debug : comme le free va vérifier les marqueurs d'allocation et qu'il ne va PAS les trouver (et pour cause...), tu vas direct dans un "Heap corruption error", et une exception qui va être levée dans ton debugger.
Dans l'autre sens, ce n'est guère mieux : ton malloc Debug va allouer un peu plus de mémoire que ce que tu as demandé (pour ces fameux marqueurs), que le free Release ne pourra PAS libérer, ou alors, seulement partiellement... Dans les deux cas, tu as une fuite mémoire.

Et ça, c'est seulement le cas le plus simple : tu as des dizaines (centaines ?) de cas vicieux pouvant se produire lorsque tu mélanges du code Release et du code Debug, sans parler de différences de comportement de certaines fonctions... La plus connue, c'est l'assertion qui est tout simplement éliminée en mode Release : dommage si tu faisais un appel de fonction important dans la condition de l'assertion, car elle va purement et simplement sauter en Release, alors qu'elle sera bien appelée en Debug...