Discussion :

[kzwix]

Bonjour,

Je suis sous linux, et j'utilise GCC ( gcc version 4.3.2 (Debian 4.3.2-1.1) )
J'ai remarqué un problème étrange en utilisant la classe string, de la STL.
Les deux lignes suivantes ne donnent pas le même résultat dans tous les cas :

cout << ma_string << endl;
cout << ma_string.c_str() << endl;

Ce n'est pas un problème d'affichage, car un parcours de la chaîne renvoyée par c_str() (via un pointeur sur caractère) me confirme qu'elle ne contient pas les mêmes données. En fait, elle est tronquée.


Voici, plus en détail, la chaine avec laquelle j'obtiens ce résultat :

INSERT INTO health.grp_data (entete_id, groupe_id, grp_data_numero_groupe, grp_data_data, grp_data_prestation_offset) VALUES (18002, 6, 1160, $$1160|000000000000|0|$$, 0) RETURNING grp_data_id

Quand je reste en mode "chaine C++", l'intégralité s'affiche.
Quand je passe en mode "chaine C", via c_str(), j'obtiens la chaine suivante :

INSERT INTO health.grp_data (entete_id, groupe_id, grp_data_numero_groupe, grp_data_data, grp_data_prestation_offset) VALUES (18002, 6, 1160, $$1160|


Comme vous pouvez le constater, elle se coupe, bizarrement, au début d'une suite de zéros. Se pourrait-il qu'elle soit interprétée, par erreur, comme une fin de chaîne par l'implémentation ?
Est-ce un problème connu ? Généralisé ?
Y'a-t'il une solution simple qui me permettrait d'éviter ce genre de problèmes ? (remplacer toutes les "string" par des objets d'une classe maison est difficilement envisageable, vu la taille de notre projet...)


Merci par avance pour vos réponses.

[Astraya]

Bonjour,
Ce fais n'est pas présent sur le compilateur de microsoft 2008. J'ai essayer avec le code suivant et la totalité s'affiche:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
std::string tmp("INSERT INTO health.grp_data (entete_id, groupe_id, grp_data_numero_groupe, grp_data_data, grp_data_prestation_offset) VALUES (18002, 6, 1160, $$1160|000000000000|0|$$, 0) RETURNING grp_data_id");
std::cout << tmp << std::endl;
const char* ch = tmp.c_str();
std::cout << ch << std::endl;

effectue tu d'autres traitements en dehors de ton exemple?

[JolyLoic]

La principale raison que je peux voir pour ce genre de comportement, c'est si la chaîne contient un '\0' (à l'endroit où elle est tronquée). En effet, ce caractère n'a aucune signification particulière pour une chaîne C++, alors qu'elle marque la fin d'une chaîne C.

[kzwix]

Bonjour,
Ce fais n'est pas présent sur le compilateur de microsoft 2008. J'ai essayer avec le code suivant et la totalité s'affiche:

effectue tu d'autres traitements en dehors de ton exemple?

Oui, il y a d'autres traîtements, mais pas entre les deux affichages. J'ai d'ailleurs tenté, après l'affichage de c_str() de réafficher la chaîne, la totalité s'affiche à nouveau. Donc, pas de perte de données entre temps, uniquement dans le résultat de c_str().

La principale raison que je peux voir pour ce genre de comportement, c'est si la chaîne contient un '\0' (à l'endroit où elle est tronquée). En effet, ce caractère n'a aucune signification particulière pour une chaîne C++, alors qu'elle marque la fin d'une chaîne C.

Ah, ça, c'est une remarque très intéressante ! En fait, je passe par c_str() pour parcourir la chaîne, et faire des conversions, caractère par caractère (plus simple, pour moi, que de passer par un itérateur). Mais, justement, peut-être qu'un parcours par itérateur révèlerait des choses intéressantes. Je vais y jeter un oeil dès demain.

Je vous tiens au courant. Merci !

[kzwix]

Ok, c'est exactement ça : Présence d'un caractère nul, évidemment non affiché, mais qui nous pourrit la conversion.

Merci encore pour les réponses !

[Emmanuel Deloget]

Ah, ça, c'est une remarque très intéressante ! En fait, je passe par c_str() pour parcourir la chaîne, et faire des conversions, caractère par caractère (plus simple, pour moi, que de passer par un itérateur). Mais, justement, peut-être qu'un parcours par itérateur révèlerait des choses intéressantes. Je vais y jeter un oeil dès demain.

Je vous tiens au courant. Merci !

Ca, c'est Interdit(tm). std::string::c_str() renvoie une chaine de caractère constante. Le standard ne dit même pas que cette chaine est effectivement stockée dans l'objet std::string. Pire, dans certains cas, une implémentation particulière peut utiliser le fait que cette chaine est constante pour proposer des optimisations (copy-on-write).

Bref: tu n'as pas le droit de modifier une chaine en passant par std::string::c_str().

Si tu souhaites la modifier, tu dois passer par les accesseurs disponibles, qui sont :

• operator[]()
• les itérateurs

Toute autre solution nécessite de passer outre les conditions définies par le standard C++, avec pour conséquence évidente que le fonctionnement de tes programmes n'est plus garanti. Tu crois que c'est plus simple - sauf que, comme tu l'as remarqué toi même, tu n'es pas à l'abri d'un bug qui va finalement te faire perdre ton temps. La simplicité en prends un coup, non ?

A noter que si tu n'as pas envie d'écrire un code trop lourd, tu peux tout à fait créer un alias de type sur les types itérateurs (avec typedef). Le code suivant se retrouve très régulièrement dans mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
void function(const std::string& s)
{
  typedef std::string::iterator i_type;
 
  // utilisation de i_type à la place de std::string::iterator. 
}

[kzwix]

Ca, c'est Interdit(tm). std::string::c_str() renvoie une chaine de caractère constante. Le standard ne dit même pas que cette chaine est effectivement stockée dans l'objet std::string. Pire, dans certains cas, une implémentation particulière peut utiliser le fait que cette chaine est constante pour proposer des optimisations (copy-on-write).

Bref: tu n'as pas le droit de modifier une chaine en passant par std::string::c_str().

Si tu souhaites la modifier, tu dois passer par les accesseurs disponibles, qui sont :

• operator[]()
• les itérateurs

Toute autre solution nécessite de passer outre les conditions définies par le standard C++, avec pour conséquence évidente que le fonctionnement de tes programmes n'est plus garanti. Tu crois que c'est plus simple - sauf que, comme tu l'as remarqué toi même, tu n'es pas à l'abri d'un bug qui va finalement te faire perdre ton temps. La simplicité en prends un coup, non ?

Houlà, j'ai pas dit que je modifiais la chaîne en elle-même, hein ! Non, je convertis le caractère lu, et j'écris le caractère obtenu dans une AUTRE chaîne. Et ça n'aurait rien à voir avec les conséquences que tu décris, puisque je parlais de ce que retournait c_str(), pas d'un massacre de ma chaîne à l'aide de pointeurs


Cela dit, merci tout de même de ton intervention. La cause de l'erreur, au final, était des caractères \0 qui se cachaient dans la chaîne, parce qu'un collègue assignait un nombre à une chaîne, au lieu d'assigner la représentation texte de ce nombre. Total, la chaîne en question prenait cet int pour un char, et comme l'int valait 0, elle prenait la valeur "\0". Quand, ensuite, on concaténait la chaîne avec d'autres, le caractère nul restait, car il faisait partie de la string... et c'est comme ça qu'on obtenait ce joyeux ratage

Donc voilà, c'est résolu de chez résolu, et j'ai appris des choses au passage. Donc merci

[Emmanuel Deloget]

Houlà, j'ai pas dit que je modifiais la chaîne en elle-même, hein ! Non, je convertis le caractère lu, et j'écris le caractère obtenu dans une AUTRE chaîne. Et ça n'aurait rien à voir avec les conséquences que tu décris, puisque je parlais de ce que retournait c_str(), pas d'un massacre de ma chaîne à l'aide de pointeurs

Il faudrait que je prenne un poste de lecteur de forum à plein temps. Sans ça, je m'apperçois que je fais des erreurs de lecture grossières