wstring, c_str() et size

Bonjour à tous,

Voici un petit casse-tête dont je ne me sors pas.
Je tente de récupérer un wstring dans un wchar, et le wchar résultant n'est pas conforme, pourtant la taille semble correcte.
Je m'explique : je m'attend à recevoir la chaine "Pouet", or je ne reçois que "P".

Code:

---

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

WCHAR wcTemp[STRING_MAXIMAL_SIZE]; std::wstring Name; // Ceci est rempli ailleurs, et vaut "Pouet" // Test 1 swprintf_s(wcTemp, STRING_MAXIMAL_SIZE, L"%s", Name.c_str()); // Test 2 wcscpy_s(wcTemp, STRING_MAXIMAL_SIZE, Name.c_str());   if (wcslen(wcTemp) < 3) { WCHAR Plop[10]; swprintf_s(Plop, 10, L"%d", my_data->my_parameter.Name.size()); MessageBox(hwnd, wcTemp, Plop, MB_OK); } // Même sur le test 3: if (wcslen(wcTemp) < 3) { MessageBox(hwnd, wcTemp, my_data->my_parameter.Name.c_str(), MB_OK); }

---

Et là, le miracle arrive :
Tests 1 et 2, la message box m'affiche, en titre, 5, et dans le texte : "P"
Test 3, la messagebox m'affiche, en titre, "P", et dans le texte : "P".
Je ne comprend pas.

Petites précisions:
1°) Ceci est fait sous WinCE6.0
2°) Ces modifications sont faites dans des threads gérants des lignes (un thread par ligne), et cela n'arrive très généralement qu'au bout de 146 lignes... Toutes les autres lignes sont bonnes ! :calim2:
3°) Lorsque j'ai déjà affiché une première fois, pas de problème lors du second affichage.

Si vous avez une idée, ou besoin de précisions, n'hésitez pas :)

Merci

Je ne connais pas trop les Windows Embedded, mais essaie en appelant explicitement MessageBoxW().
Edit: Peut pas être ça, car ce serait systématique.

Vérifie qu'il n'y a aucun risque qu'un autre thread modifie l'une de tes variables.

Salut Médinoc,

Merci pour ta réponse.
Pour le coup du MessageBoxW, en fait, c'est bien celle-là qui est appelée, car le MessageBox est un #define qui renvoie vers MessageBoxW (Unicode)

Je ne vois vraiment aucun thread susceptible de modifier cette donnée.

Je connais la string qui doit s'afficher. Que je mesure la taille avant ou après la récupération de la string par un swprintf_s ou par un wcscpy_s, la taille de la string est bonne, le texte est faux (un seul, zéro ou plusieurs caractères).
Au deuxième passage, je n'ai pas de problème.

Je ne vois vraiment pas du tout d'où peux venir le problème.

Le plus dingue, c'est que si, avant d'afficher toutes les lignes (149), j'affiche tous les textes dans une grande MessageBox, les lignes sont TOUTES correctes.
Si je force un nouvel affichage, les lignes sont TOUTES bonnes.
Sans déconner, j'en peux plus :calim2: :aie: :massacre::help:

Salut,

Un petit mot pour dire que le problème est résolu, et évidemment, l'explication (en tout cas, celle que je peux en faire).
Et le problème ne vient pas de là où je l'attendais, comme d'habitude.

Le problème n'apparait que sur Windows CE 6.0 (128MO de RAM), non pas sur mon PC (Windows 7 32 bits avec tout plein de RAM). Ensuite, il n'apparait que lors du premier affichage : lors des suivants, tout se passe correctement.
Cela ressemble donc à un problème de gestion de la mémoire : mes nombreux paramètres sont stockés dans un "std::vector", et je suppose que la taille réservée lors du premier passage n'est pas bonne, qu'il faut ajouter de la place, puisqu'au deuxième passage, la place est déjà réservée, et tout se passe correctement.
J'ai donc réservé (avec la fonction tout bêtement "reserve") par défaut la taille maximale possible des paramètres (qu'heureusement je connais), et tout se passe bien depuis, le problème ne se répète plus.

J'espère avoir été clair, et avoir résolu le problème (et non caché en pensant avoir compris).

À plus tard

PS : Windaube CE, quelle dows :aie:

Citation:

---

Envoyé par jacklafrip

mes nombreux paramètres sont stockés dans un "std::vector", et je suppose que la taille réservée lors du premier passage n'est pas bonne, qu'il faut ajouter de la place, puisqu'au deuxième passage, la place est déjà réservée, et tout se passe correctement.
J'ai donc réservé (avec la fonction tout bêtement "reserve") par défaut la taille maximale possible des paramètres (qu'heureusement je connais), et tout se passe bien depuis, le problème ne se répète plus.

---

Hmm cette solution "solution" laisse fortement penser que l'erreur vient plutôt d'une mauvaise utilisation de std::vector qu'autre chose.

Accuser wince est un peu ridicule ici vu que le code de la bibliothèque standard est identique entre windows desktop et wince pour une même version de visual studio. Il est plus raisonnable de penser qu'une erreur dans ton code déclenchait un comportement indéterminé, ce qui peut effectivement donner des résultats différents de système à système.

De tête je dirais qu'il y a deux scénarios assez fréquent dans lequel un reserve peut soit masquer soit corriger un problème :

Code:

---

1 2 3 4

std::vector<std::wstring> v; v[0] = "param0"; v[1] = "param1"; v[2] = "param2";

---

Ce genre de code provoque un comportement indéterminé (souvent un crash)
Alors que l'utilisation correcte est :

Code:

---

1 2 3

v.push_back("param0"); v.push_back("param1"); v.push_back("param2");

---

Le truc, dans le premier c'est que si l'on rajoute un reserve après la déclaration de v, le code est toujours faux, mais il y a plus de chance que le comportement indéterminé soit plus subtil et ne crash pas systématiquement. C'est un cas où ajouter un reserve masque le problème.

De manière générale lorsqu'on l'on fait v[i] = qqchose, il faut bien s'assurer que v.size() > i

Deuxième cas, où cette fois le reserve() est justifié et corrige le problème :

Code:

---

1 2 3 4 5 6 7 8 9 10

std::vector<std::wstring> v; v.push_back("param0"); std::wstring* ptr0 = &v[0]; foo(ptr0); v.push_back("param1"); v.push_back("param2"); v.push_back("param3"); v.push_back("param4"); foo(ptr0); // erreur ici !!

---

ptr0 est probablement invalide maintenant car il est très probable que le vecteur suite à un push_back pour s'agrandir a du réallouer son buffer interne, donc le pointeur pointe maintenant sur une zone de mémoire invalide.

Dans ce cas, faire un v2.reserve(TAILLE_MAX) est une bonne solution et corrige effectivement le problème car on a alors la garantit après le reserve que le buffer interne est suffisament grand pour qu'aucune réallocation ne soit nécessaire pendant l'utilisation du vector, donc tout pointeur pointant dans le vecteur restera valide.

Je conseillerais plutôt resize() que reserve() selon le cas, car sinon j'ai l'impression qu'il est possible d'appeler operator=() sur un objet non construit (mais je peux me tromper).

Pour autant que je sache, le message de Arzar est parfait...