salut,
 
j'avais un très joli seg fault sous linux et j'ai eu un peu de mal a le trouver. Ca venait du code suivant :

 
en fait sous win avec vc++ ou bcb pas de probleme. Alors que sous linux avec gcc => plantage.
Avec un cout << s.capacity() on voit tout de suite que sous win la chaine est allouee mais pas sous linux. Il faut en fait soit faire un s.resize ou apres le reserve initialiser la chaine :
s = "glop" et la pas de pb.
 
Alors c'est quoi ce delire ?

enleve ton cast et regardes ce que te dis ton compilateur

 
gcc ->  passing `const char *' as argument 1 of `strftime(char *, unsigned int, const char *, const tm *)' discards qualifiers
 
et vc++ -> error C2664: 'strftime' : cannot convert parameter 1 from 'const char *' to 'char *'
 
ben voila et c'est normal, fo caster

       si c_str() renvoie un const char * c'est pas pour des prunes, c'est jsutement parce qu'on peut pas ecrire dedans
 
c'est un pointeur vers une zone allouée en plus de la représentation interne de la string afin d'offrir un compatibilité avec cstring par exemple
 
 

caster un const char *      
 
et tu t'étonnes d'avoir un segmentation fault ???
ne me dis pas que t'as pas eu un warning en compilant ??

d'ailleurs il vaut mieux faire un const_cast

Les cast sont dangereux.
Ils ont l'air serviables, mais ils attendent qu'on ait le dos tourné pour nous mordre.
 
En toute logique, on ne copie pas manuellement une chaîne C dans une string C++.
On peut écrire dans un buffer, puis initialiser une string avec.

Harkonnen a écrit a écrit :   caster un const char *         et tu t'étonnes d'avoir un segmentation fault ??? ne me dis pas que t'as pas eu un warning en compilant ??

les const c'est juste pour faire des verifications au niveau de la compilation. A l'execution ca ne change rien. Ce que je voulais savoir c'est pourquoi quand je fais un reserve, aucune allocation n'est faite.
 
Musaran-> ouais mais c'est lourd de devoir passer a chaque fois par un buffer intermediaire pour initialiser une string.
 
Et pis pourquoi ca marche sans probleme sous Win et pas sous Linux?

 
L'implementation de la string est libre. L'important est de suivre le standard, et le standard c'est que le pointeur renvoyé par c_str() est const char *, il n'y donc pas lieu d'y ecrire.
 
Rien, Absolument rien, ne te garenti que le pointeur renvoyé par c_str pointe sur la memoire allouee pour la string.
Certaines implementations de string ont deux buffers, l'un fixe pour les petites chaines, et l'autre variable.
 
ta commende reserve provoque alors l'allocation du grand buffer, mais la chaine de ta string n'en ayant pas besoin, c_str te renvoie un pointeur sur le petit buffer...
 
effectivement le const est là pour la compilation, après que cela ne change rien a l'execution, c'est une affirmation un peu rapide !
 
Bien sur il n'y a pas de systeme de verification pour s'assurer à l'execution que tu ne le fait pas, mais tu entres dans le domaine des consequences indefinies...
 
Tu dis que cela se passe bien en Win32, en es-tu sur ?
Sur le cas que tu as testé peut-etre, mais attention aux effets de bords. Certaines implementations de strings font des references comptées, c'est dire que quand tu copies une string la chaine n'est pas copiée immediatement, mais uniquement quand l'une des deux chaines est modifiée...   Or si tu modifie la chaine par c_str() l'objet string n'est pas au courrant des modifications. De plus dans une prochaine release du compilo l'implementation de la string peut-etre modifiée... Et alors a toi de retrouver un bug dont l'orgine sera pour le moins mysterieuse...
 
caster un const char * ? oui, bien sur, je l'ai nsouvent fait...
Car je savais que la fonction (que je ne maitrisait pas) sous-jacente prenait un char * et ne le modifiait pas. Bien entendu ce cast etait documenté et faisait l'objet d'un jeu de tests pour s'assurer que la fonction sous-jacente ne se mettait a modifier la chaine...
 
Enfin pour conclure : a qui la faute ? a toi !

merci bcp
 
 

 
bah we et encore heureux !  

 
ptdr, tu comprends rien a rien mon gars...

 
Mais te gene pas, eclaire moi de ton immense savoir au lieu de balancer des posts aussi constructifs.
T'as un tres bon exemple avec BENB.
 

Certes, mais si le "const" est la, c'est pour une bonne raison !
C'est comme si tu achetais une voiture à essence et que tu la faisais rouler au diesel parce que c'est moins cher !
 
Moi ce que je vois, c'est que tu utilises les avantages du C++ (la string), et la souplesse d'utilisation du C, pour un mélange batard et dont la fiabilité est aléatoire ! La preuve...
 
Quant au fait que ça fonctionne avec BCB ou VC++, regarde donc si tu n'as pas compilé en mode Debug, ça ne m'étonnerait pas du tout...
 
Enfin moi, si je souhaitais strftime(), il ne me serait jamais venu à l'idée d'utiliser une string, mais un bon vieux buffer des familles :

pas de cast, pas de warning, et 100% portable.

c'est vrai que ca m'apprendra a jouer les radins    
et dans ce cas la, le mélange c/c++ ca faisait carrément dégueu, je l'accorde. Mais ce n'etait pas ma question.
 
[citation]
Quant au fait que ça fonctionne avec BCB ou VC++, regarde donc si tu n'as pas compilé en mode Debug, ça ne m'étonnerait pas du tout...
[/citation]
Compilé en mode release, desolé