Comportement très étrange pour CString

Bonjour à tous,

Je suis bloqué depuis ce matin sur un problème assez .. énervant..

Quand je déclare un CString, il est directement remplit avec le texte "Yes", ce n'est pas un énorme problème, mon énorme problème vient du fait que la fonction Empty() est tout simplement ignorée, aucun effet.
Idem pour une simple allocation = "";

Quand je trace en mode debug, la string générée semble être une cstring ATL, or je pensais utiliser des cstring MFC, celà ne joue peut être pas dans mon problème mais on ne sait jamais..
Je finis par dire qu'aussi bien ATL que MFC sont linké en static..

Est ce que quelqu'un à une idée voir même un début de piste?
N'hésitez pas si je ne suis pas clair, j'ai certaine difficultés à décrire ce problème.... :(

Merci à vous,

Francois

salut,
cette valeur n'arrive pas (et ne peut arriver) toute seule ...
il faut chercher dans le contexte d'utilisation de cette CString.
par exemple :
dans une boite de dialogue si celle-ci est rattachée a un contrôle
un UpdateData peut changer sa valeur.
mais bon c'est un exemple....

Hello,

Merci pour la réponse, malheureusement, les CString qui ont ce comportement n'ont pas toutes un lien avec du GUI, donc pas non plus d'UpdateData();

Au niveau du contexte d'utilisation, même problème, il y a un peu de tout.
Le contexte le plus fou est quand même une déclaration sans allocation en tout début de fonction, première instruction, et même là, je démarre avec le fameux "Yes".

J'imagine bien que cette valeur ne vient pas toute seule, mais je ne vois absolument pas d'où cela pourrait venir..
D'autres idées?


Francois

comment veux tu que l'on réponde à ça sans inspecter ton code ?
raisonnement logique à suivre :
ce comportement est impossible par défaut, donc ça vient forcement de mon code que je vais éplucher pour trouver.
une recherche générale sur le mot "Yes" dans ton projet me semble un préalable.

Citation:

---

Envoyé par squale32

Quand je trace en mode debug, la string générée semble être une cstring ATL, or je pensais utiliser des cstring MFC,

---

Si, c'est correct, c'est CString ça !!
Je dirai même plus "cette valeur n'arrive pas (et ne peut arriver) toute seule ..."

Je veux bien balancer du code mais ce n'est pas local, j'ai ce comportement un peu partout (une trentaine de projets :aie:), exemple:

Code:

---

1 2 3 4 5

void CAA::fct_a() { CString sMyString; }

---

Et bien juste avec cela, j'ai du "Yes" dans ma string :(
La recherche sur le "Yes" n'a rien donné, c'est un yes magique..

Petite info que j'aurais peut-être du donner dès le départ, ce bug survient alors que je viens de migrer de vs6 à vs9 (vs2008) et après installation du feature pack mfc/tr1.
Bien que je ne vois pas ce que ça pourrait changer, pensez vous que ça joue?


Je comprends vraiment pas ce qu'il se passe..

Essaie de faire ça au démarrage, dans ton main (ou si tu es dans un prog graphique, dans le constructeur de ta CWinApp). Je pense que le problème ne devrait "pas encore" se produire.

En fait, je pense qu'un truc modifie l'instance partagée de CString vide et la remplace par "Yes".
Par exemple, un strcpy() malheureux sur une CString avec un cast qui vire le const... (et selon toute probabilité, un cast C-Style plutôt qu'on const_cast :( )

Citation:

---

Envoyé par squale32

Code:

---

1 2 3 4 5

void CAA::fct_a() { CString sMyString; }

---

Et bien juste avec cela, j'ai du "Yes" dans ma string :(

---

Une redéfinition de la classe CString qui traine :koi:?

j'ai 2008 avec le pack MFC/TR1 a la maison ,je n'ai rien constaté de tel ...
tu peux faire un petit projet MFC qui ne depend de rien avec une CString qui met le problème en évidence ?

J'ai fait un petit projet sur le côté mais je ne reproduit pas mon problème, de même un projet dans la solution concernée ne m'aide pas non plus à reproduire.

J'ai aussi chercher après une redéfinition de la classe CString, mais de nouveau je n'ai rien trouvé qui allait dans ce sens là.

Par contre:

Code:

---

1 2	if ((r = RegQueryValueEx(hk, "Check_it", NULL, NULL, (unsigned char*)(LPCTSTR)res, (unsigned long*)&Val)) != ERROR_SUCCESS)

---

En effet, après cette ligne là, tous mes CString sont par défault avec "Yes" comme data:cry:
Je vais chercher dans les autres projets, mais ca devrait être à peu près les mêmes erreurs partout..

Comment puis je modifier cette ligne pour qu'elle soit correct par rapport au cstring??

Prosternez-vous devant mon pouvoir de divination :king:

Remplacer par ceci:
reinterpret_cast< unsigned char* >(res.GetBuffer(<taille>))
Puis, faire res.ReleaseBuffer().

Note que tu peux aussi remplacer unsigned char par BYTE dans le cast.

Citation:

---

Envoyé par Médinoc

Prosternez-vous devant mon pouvoir de divination :king:

---

:mouarf:

Citation:

---

Remplacer par ceci:
reinterpret_cast< unsigned char* >(res.GetBuffer(<taille>))
Puis, faire res.ReleaseBuffer().

Note que tu peux aussi remplacer unsigned char par BYTE dans le cast.

---

J'ai jamais réellement bien compris cette histoire de reinterpret_cast donc j'ai fait la moule, j'ai remplacer le CString par un tableau de char :roll:


merci à vous pour le support :yaisse2:


EDIT: un truc comique, ce code existe depuis l'été dernier et jamais avant hier je n'avais eu l'erreur...

pourtant ça débordait un max en mémoire ...

Citation:

---

Envoyé par farscape

pourtant ça débordait un max en mémoire ...

---

Je ne comprends pas la remarque.

j'interprète cette erreur de la façon suivante: c'est le fait d'accéder directement aux données - dynamique - du CString qui pourrissait la "copie interne du constructeur" ( ?), démarrant à chaque fois avec les data "Yes".

Maintenant, j'ai toujours du mal à comprendre comment ça peut arriver..
Je sais par contre que jamais plus je ne ferai de double cast de ce type (LPTSTR)(LPCTSTR). :lol:

Donc remplacer par mon tableau n'est pas une mauvaise solution si?

Les CString utilisent du Copy-on-write, avec un comptage de références intrusif sur des données CStringData.
Et le constructeur par défaut de CString, plutôt que d'allouer une nouvelle CStringData pour une chaîne vide, acquiert à la place une référence vers une CStringData "chaîne vide" partagée.

Et ton accès illégal en écriture a pourri cette CStringData...

Tiens, je remonte le thread pour une précision: Si tu ne comprends pas ce qu'est un reinterpret_cast<>, c'est que tu as besoin, de toute urgence, d'un cours sur les casts C++, qui t'expliquera pourquoi les casts C-style sont à éviter (parce qu'ils autorisent tout et surtout n'importe quoi).