[MFC] Bug surnaturel (transformation CStringList -> char*

Version imprimable

Bonjour,

Je développe une fonction qui transforme un CStringList en char**, selon le code suivant:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 void Appli::CStringListToPPChar(int& nbElements, char** tableau, CStringList* liste) { nbElements = 1; tableau = new char*[1]; tableau[0] = _T(""); if (! liste->IsEmpty()) { nbElements = liste->GetCount(); tableau = (char**)malloc(nbElements*sizeof(char*)); POSITION pos = liste->GetHeadPosition(); int i = 0; CString elementCourant; while(pos != NULL) { elementCourant = liste->GetNext(pos); tableau[i] = elementCourant.GetBuffer(1024); //Bug ici //elementCourant.ReleaseBuffer(); i++; } } }
On pourrait se dire que c'est correct, sulement quand j'affecte sa valeur a

Code:

tableau[i]

, n'est pas modifié seulement l'élément en i, mais tout le tabeau, et dès que je refais un tour de boucle, toutes les valeurs se réinitialisent!!

J'avoue que la, je suis totalement sidéré et désemparé...
Et si j'ouvrais mon PC pour voir s'il y aurait pas un esprit frappeur dedans ca marcherait mieux à votre avis?

MErci d'avance pour votre aide
[/code]

29/04/2005, 12h26
la drogue c'est mal

il est vraiment bizzare ton code:

1) tu passes 2 fois le meme parametres. nbElements étant un information contenu dans CStringList

2) tu melanges du C++ avec du C. Je vois pas ce que vient faire malloc dans cette histoire.

3) tu n'as pas bien compris l'utilisateur de GetBuffer() du CString

laisse tomber le démontage de ton pc et passe plutot au demontage de ton code
29/04/2005, 12h32
eyghon

1) nbElements est une valeur que je modifie dans ma fonction pour une utilisation après cette méthode (d'où le int&, paramètre par référence)

2)la différence entre malloc et l'opérateur new pour les types primitifs est quasiment nulle, l'opérateur new faisant ne faisant qu'appeler le constructeur des classes en plus (et, à moins que cela ait changé, y'a pas de constructeur pour les type primitifs). Et puis j'avais fais une version avec le new qui ne marchait pas mieux.

3) GetBuffer retourne bien le char* correspondant au CString non? C'est exactement ce dont j'ai besoin.

Merci de ton aide en tout cas ( ca fait mechant comme post mais ca l'est pas!)
29/04/2005, 13h11
farscape

de toute façon ce que tu as ecris ne peux fonctionner .
la memoire allouée par GetBuffer est relachée apres destruction de l'objet CString. (voir MSDN).
qui dans ton cas est local à la fonction...
pourquoi ne pas gerer un tableau de CString du style CArray<CString ,const char *> ?
:D
29/04/2005, 13h29
eyghon

C'etait bien le GetBuffer qui posait probleme.
Résolu en faisant un simple cast tout bete (char*)(LPCSTR)elementCourant;

J'avais totalement zappé le coup de la destruction. Merci a vous deux en tout cas!
29/04/2005, 15h15
la drogue c'est mal

Citation:

1) nbElements est une valeur que je modifie dans ma fonction pour une utilisation après cette méthode (d'où le int&, paramètre par référence)

certes mais l'information est contenu dans CStringList donc ce parametre est, d'apres moi, inutile

Citation:

2)la différence entre malloc et l'opérateur new pour les types primitifs est quasiment nulle, l'opérateur new faisant ne faisant qu'appeler le constructeur des classes en plus (et, à moins que cela ait changé, y'a pas de constructeur pour les type primitifs). Et puis j'avais fais une version avec le new qui ne marchait pas mieux.

certes mais le mélange de code C et C++ entraine des confusions de la part du developpeur. Ca demontre une mauvaise maitrise du C++

Citation:

3) GetBuffer retourne bien le char* correspondant au CString non? C'est exactement ce dont j'ai besoin.

non

Citation:

C'etait bien le GetBuffer qui posait probleme.
Résolu en faisant un simple cast tout bete (char*)(LPCSTR)elementCourant;

J'avais totalement zappé le coup de la destruction. Merci a vous deux en tout cas!

le LPCTSTR signifie const char*. Le const n'est pas la uniquement pour faire jolie mais pour proteger l'intégriter des informations.

en faisant cela tu autorises une modification d'une variable "private" de la class CString ce qui aura pour consequence un probable crash difficilement detectable.