[résolu]sf::String crash en release mais pas en debug

[samplay]

Bonjour,
un programme test avec une seule ligne (!) dans "main"...
sf::String("test");
en version Debug crashe avec sfml 2.1 en dll-release, mais ne crash pas avec sfml 2.1 en dll-debug.
Ceci en 32 bits sous windows 7, compilé sous vc9 , avec sfml 2.0 comme avec 2.1, que sfml provienne
des packages vc9-32 precompiles du site ou aie été recompilés par moi-meme.
Sauf erreur, le pb se produit dans basic_string::reserve().
Je n'ai pas l'impression que le probleme existe si TOUT ( le mini-programme ET SFML) est en release, mais j'ai l'habitude de toutes facons de pouvoir utiliser les libs externes en release quand je teste mes programmes en debug.
 par ailleurs, le cmake ne permet plus semble -t-il de creer une compilation sfml en statique:me -trompé-je?
j'ai cerné le pb au maximum de mes capacités alors merci d'avance aux experts qui voudront bien se pencher sur le probleme.

[Laurent]

en version Debug crashe avec sfml 2.1 en dll-release

En rouge dans le tutoriel de démarrage :

Il est important de lier les bibiothèques qui correspondent à la configuration : "sfml-xxx-d.lib" pour Debug, and "sfml-xxx.lib" pour Release. Un mauvais mélange pourrait entraîner des crashs.

j'ai l'habitude de toutes facons de pouvoir utiliser les libs externes en release quand je teste mes programmes en debug.

Alors il s'agit sans doute de bibliothèques C, ou de bibliothèques C++ qui n'ont aucune utilisation de la bibliothèque standard dans leurs en-têtes. Ce qui n'est pas le cas de SFML.

[samplay]

Merci pour les réponses,
1. j'utilise bien les libs qu'il faut, cela ne vient pas de la.
2. le probleme disparait si je mets un L majuscule devant mon texte comme suit...
sf::String(L"test");
ce qui ne résoud pas mon probleme initial ( j'ai besoin de faire accepter un const char * "a l'ancienne"), mais je vivrais avec.
3. on ne doit pas s'etre compris sur les libs externes: j'utilise comme tout le monde, entres autres, glu32, opengl32, tinyxml ( en version STL), CEGUI, Devil, mes propres libs qui utilisent std:: et STL, etc... et ce dans leur version release meme quand le programme qui les inclut est en debug: ca ne me parait pas aberrant, dans la mesure ou ces libs sont censées etre débuggées en amont.
Merci enfin pour tout ce boulot partagé sur SFML.

[Laurent]

1. j'utilise bien les libs qu'il faut, cela ne vient pas de la.

Ca contredit ton commentaire précédent, qui parle d'utiliser les libs release en mode debug.

3. on ne doit pas s'etre compris sur les libs externes: j'utilise comme tout le monde, entres autres, glu32, opengl32, tinyxml ( en version STL), CEGUI, Devil, mes propres libs qui utilisent std:: et STL, etc... et ce dans leur version release meme quand le programme qui les inclut est en debug: ca ne me parait pas aberrant, dans la mesure ou ces libs sont censées etre débuggées en amont.

Ce n'est pas une histoire de debugger ces bibliothèque, c'est une histoire de faire parler le même langage à deux binaires qui échangent des données.

Plus concrètement, si j'ai ça :

// Lib.dll

std::string blop();

// Prog.exe

std::string s = blop();

... ça va très probablement crasher avec Visual C++ car il n'a pas la même définition de std::string lorsque le binaire a été compilé en mode release et en mode debug. En mode debug, certains champs sont ajoutés (par exemple). Du coup ta DLL t'envoie une instance std::string qui ne correspond pas à la définition que ton programme a, et lorsque tu essayes de l'utiliser tu as un comportement indéfini (crash, corruption mémoire, rien de visible, etc.).

[samplay]

bonjour,
1. Je n'avais pas compris ton commentaire,  que j'ai associé a une utilisation incompatible d'une Dll dans un mode ( ex debug), avec un programme principal compilé avec l'autre version de la lib de la dll ( ex release).
2. Si la fonction dans SFML avait pour argument un CHAR au lieu d'un wchar_t, cela ne résoudrait t-il pas le probleme ( sous windows) de pouvoir travailler avec des char et non obligatoirement des wchar_t?
3. J'en apprend tout les jours! j' ai implanté le changement de taille entre debug et release et conclut apres avoir oublié le code et perdu du temps sur des bugs incomprehensibles, que c'etait une c...rie de ma part. Je ne m'attendais vraiment pas a ce que Visual C++ le pratique!
Merci pour ton attention.

[Laurent]

2. Si la fonction dans SFML avait pour argument un CHAR au lieu d'un wchar_t, cela ne résoudrait t-il pas le probleme ( sous windows) de pouvoir travailler avec des char et non obligatoirement des wchar_t?

Je ne comprends pas ton commentaire. sf::String sais traîter les deux, char et wchar_t. Tu lui files ce que tu veux, il n'y a aucune obligation de quoique ce soit.