Problème avec la methode c_str()

Bonjour,

comme c'est marqué dans le titre du topic, j'ai un problème avec la méthode c_str() de la classe std::string.
Voici le contexte : je récupère des informations via un recv sur un socket, à chaque recv je met ce que j'ai reçu dans un char*, puis je rajoute cette chaîne à un std::string, jusqu'à que j'ai tout reçu.
Quand je regarde la taille du contenu de mon std::string via la méthode length(), j'ai bien quelque chose de correcte, mais lorsque j'appelle c_str() pour vérifier le contenu, ça me retourne une chaine courte de 4 ou 5 caractères, toujours la même, qui serait je suppose une adresse.

Merci d'avance pour l'aide que vous pourrez m'apporter.

n'y aurait-il pas des caractères non imprimables dans ta chaîne ?

Ce n'est pas ça le problème, le std::string contient bien la bonne chaine, je l'ai affiché et c'est nickel (y'a en moyenne plus de 35000 caractères dedans, voir bien plus), mais c_str() me renvoie une suite de quelques caractères (4 ou 5) et toujours les même. Je pensais à une adresse, mais c'est peu probable que ce soit exactement la même à chaque fois.

tu peux nous montrer comment tu fais stp? Moi je ferais plutôt un truc comme ca:

Code:

---

1 2 3 4

size_t size = tonstring.size() + 1; char* chaine = new char[size]; strncpy(chaine,tonstring.c_str(),size);

---

C'est bien beau grutt, mais dans ton exemple tu utilise la méthode c_str(), cette méthode même qui me pose problème.

J'ai un char[1500] (1500 représentant la taille d'un packet), et lorsque je fais un recv, à chaque tour de boucle je rajoute dans mon std::string le contenu du char[1500], via la methode append() pour rajouter pile ce que j'ai reçu.

Salut,

Effectivement, la fonction c_str() de la classe string renvoie... un pointeur sur le premier élément la chaine de caractères "C style" équivalente au contenu de la chaine :P

Mais, ce que j'ai le plus de mal à comprendre, c'est dans quel but tu souhaites transformer cette chaine std::string en chaine "C style", alors qu'une bonne partie de ton travail a, justement, consisté à... créer une chaine std::string sur base de chaines "C styles" récupérées par ailleurs.

Je ne veux certainement pas dire que tu ne dois pas le faire, mais je veux insister ici sur le fait que le seul cas "cohérent" dans lequel tu voudrais le faire est d'effectuer une analyse (sémantique ou syntaxique) de cette chaine ou de convertir la chaines en "autre chose" (ce qui revient quelque part à passer par une analyse de la chaine)...

Et, dans ce cas, ce n'est, à mon sens, pas par une chaine "C style" qu'il et intéressant de passer, mais bien par... un flux de conversion stringstream (ou toute autre méthode de récupération de données sauvegardée) ;)

Je fais ça pour une raison bien sûr. J'utilise le framework Qt4, le std::string contient en fait une image jpeg que je dois passer en argument à la méthode loadFromData de la classe QImage, cette méthode demande un uchar (autrement dit un unsigned char*).
Par ailleurs je viens de tester quelque chose et je trouve cela assez surprenant, lorsque j'utilise c_str() pour écrire dans un fichier (en faisant fichier.write(buffer.c_str(), buffer.length()) ), le contenu y est bien inscrit.

Tu veux dire que ta std::string contient des données brutes, contenant potentiellement des octets nuls?

Je crains alors que l'utilisation de la classe string ne soit pas vraiment adaptée à ton problème...

En effet, il faut se rappeler qu'une chaine de caractères est à considérer comme un tableau de caractères particulier:

1. la chaine est considérée comme étant finie au premier caractères '\0' rencontré
2. certains caractères ne sont pas affichables (en gors, tous ceux qui se trouvent aux indexes 0 à 31 inclus de la table ASCII)
3. ...

Or, une image jpeg est une image... compressée, qui doit donc être considérée comme une série de données binaires, et qui disqualifie de facto toute tentative de considérer ces données comme... de simples caractères "utilisables dans une chaine de caractères".

Ce que tu devrais utiliser, c'est un système de "buffer", qui pourrait, pourquoi pas, consister en un vecteur de caractères, et qui pourrait (première proposition venue "à chaud", donc, forcément susceptible d'être améliorée) ressembler à

Code:

---

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

/* soit buff est le buffer récupéré par recv et  * len est la taille du buffer en question  */   /* S'il n'y a qu'une seule récupération de données */ std::vector<char> tab(&buff[0],&buff[0]+len); /* si tu dois "concaténer" plusieurs récupérations de données */ std::vector<char> tab; while (recv(buff,len, flags)!=0) { tab.insert(tab.end(),&buff[0],&buff[0]+len); } /* pour récupérer le contenu réel sous la forme d'un char* */ char* final=&tab[0]; }

---

À mon avis, std::string peut tout-à-fait marcher, mais il faut s'assurer que tout ce qui dépend de la longueur de la chaîne utilise std::string::length() et absolument pas strlen() ni un équivalent: length() retournera toujours la longueur réelle de la chaîne, alors que strlen() et équivalent supposent une chaîne C (terminée par un caractère nul).

Citation:

---

Envoyé par Médinoc

Tu veux dire que ta std::string contient des données brutes, contenant potentiellement des octets nuls?

---

A vrai dire, l'octet nul n'est qu'un des caractères qui puisse poser problème...

Je pense notamment aux caractères BELL, BS, CR, CAN et tant d'autres de la table ASCII qui risquent de provoquer certains désagréments si on essaye de les utiliser dans une chaine de caractères :D

Citation:

---

Envoyé par Médinoc

À mon avis, std::string peut tout-à-fait marcher, mais il faut s'assurer que tout ce qui dépend de la longueur de la chaîne utilise std::string::length() et absolument pas strlen() ni un équivalent: length() retournera toujours la longueur réelle de la chaîne, alors que strlen() et équivalent supposent une chaîne C (terminée par un caractère nul).

---

De fait, mais c'est la raison pour laquelle je préfères (mais tu as peut etre des raisons valables de me contredire sur ce point ;)) considérer les données récupérées comme s'il s'agissait de donner de n'importe quel type différents du caractères, et les placer, "simplement", dans un tableau "classique" plutôt que dans une classe qui "traine avec elle" la notion de chaine de caractères... affichables ;)

Vous venez de confirmer mes doutes, j'avais penser que cela pouvait venir du fait que ce soit des données binaires, mais en effet je n'avais pas pensé que certains octet seraient considérés comme des '\0'.
La solution que tu propose koala01, m'était venu à l'esprit, et maintenant que vous m'avez ouvert les yeux, tu as tout as fait raison.
Je vais implémenter tout ça, mais je vais peut-être plûtot utiliser un QByteArray, fournis par Qt.

Et puis quel imbécile je fait, bien sûr que ça marchait mon histoire avec le fichier puisque j'écrivais dedans en mode binary...

Le QByteArray de Qt est, peut être, une solution adéquate, mais...

N'oublie pas non plus que cela introduit une dépendance envers Qt bien plus loin dans ton code "métier"...

Tu peux, tout à fait, te baser sur le fait que même le code métier sera systématiquement utilisé avec Qt, mais, ce sera bloquant si tu souhaite être en mesure d'utiliser ton code méter avec, pourquoi pas, bibliothèque différente de Qt (WxWidget, VCL ou framework microsoft).

N'oublie pas que toute décision à ce niveau est susceptible d'apporter autant d'avantages que d'inconvénients, et qu'il faut donc prendre la peine de faire la balance par rapport à tes objectifs ;)

Je suis tout à fait d'accord avec toi, c'est vrai qu'en utilisant un QByteArray, surtout dans cette partie de mon code, je restreint la compatibilité à ce framework uniquement.
Le logiciel que je conçois est en fait un projet de fin d'étude, et je ne prévois pas d'utiliser un autre framework. Puis au pire, je vais en faire 2 versions, une avec un QByteArray et l'autre avec une solution standard, j'archiverai cette dernière, au cas où qu'un jour je puisse en avoir besoin.

Je te remercie de tes bons conseils koala01.
Je vais demander à mon coéquipier d'effectuer les changements en conséquence sur sa partie pour qu'elle puisse fonctionner avec la mise à jour que je viens d'effectuer dans mon code. Je mettrai en résolu à ce moment là si le problème a disparu :) .

La remarque avait surtout pour objectif de t'inciter à suivre le raisonnement jusqu'au bout ;)

Pour le reste, une fois que tu a pris les décisions qui te semblent adaptées au projet et à ses évolutions, il n'y a pas de mauvais choix ;):D