Bonjour,  
Si j'ai bien compris les conseils donnés dans ce forum, il ne faut plus utiliser les char * et char[] pour les chaînes de caractères, mais std::string. D'accord, je vais essayer...
 
Premier problème :
 
string szBuffer;
//blabla pour initialiser szBuffer avec un nom de fichier
stream=fopen(szBuffer,"w" );
Mon compilateur ne veut pas d'un string comme premier argument, et je dois donc passer par szBuffer.c_str(). Pas très joli, autant garder les char *.
Mais bon, j'ai aussi lu qu'il faut éviter fopen et cie, et utiliser
fstream.
 
Comme par exemple :  
fstream f("test.txt",ios_base::in | ios_base::out | ios_base::trunc);
question : à quoi correspond le second argument? Fichier ouvert en in/out? mais c'est quoi le io_base::trunc.
 
Ensuite, ce fichier existe déjà, et comporte plusieurs ligne que j'aimerais lire. Quand je fais :  
f.getline(szBuffer,300); même problème que tout à l'heure, le compilateur veut un char *, je ne peux donc pas utiliser les strings?
 
Aussi, j'aimerais bien insérer une ligne à un endroit particulier du fichier, et non à la fin comme le mode append du fopen, c'est possible avec fstream?
 
Merci d'avance de votre aide...  

 
Non. les char *, c'est nul moche affreux et chiant. Ca plante de tous les cotés. Ca craint. continue sur std::string, quitte a faire du c_str() quand le besoin s'en fait sentir
 
 

 
ben la faut aller voir la doc hein ? la msdn par exemple te renseignera avec plaisir. Ca décrit le mode d'ouverture de fichier. les '|' sont la pour 'additionner' les parametres
 
 
 
 

 
cf std::getline
 
 

 
nope, ca va etre un brin bordelique, fo ecraser la fin du fichier avec tes nouevlles données et remettre au cul les vieilles données (que tu viens d'ecraser). 'videmment, pour ca faut les avoir sauvé qqpart

Je vais peut-être me faire taper dessus, mais moi j'utilise les char * (et les strcmp, strcpy, strcat, etc qui vont avec), et ça me pose pas de problème... mais bon, ça reste d'un usage anecdotique, je fais pas des traitements de texte ou des trucs comme ça...

Merci pour ta réponse chrisbk.
Je me doutais bien qu'il fallait persévérer avec les string    
 
MSDN est ma source d'inspiration (enfin bon...) donc c'est là que je vais pour les infos. Le problème c'est quand je ne trouve pas / comprends pas...
 

 
Si j'ai bien compris, le contenu du fichier est détruit à l'ouverture ?  
 

 
Moui, mais je ne comprends toujours pas... il faut fournir un char * où stocker le résultat, donc comment lui passer un string (ne pas mal interpréter...)? string::c_str() ne marche pas bien sûr, puisque c'est un pointeur sur un constant...
 
Désolé de ne pas tout capter du premier coup...

getline(stream, string, delimiter)

 
pas std::string::getLine mais std::getLine
 
genre la  
http://www.google.fr/search?q=cach [...] line&hl=fr

mouais ton post est plus complet que le mien

Ok, merci bien!

Bon, les problèmes continuent.
 
J'ai cherché sur le web en vain, d'ailleurs si vous avez un lien sur une bonne doc, n'hésitez pas...
 
J'ai donc essayé std::getline, et tout va bien pour le stocker dans une chaîne string, par contre, je cherche sans succès une fonction similaire pour lire n caractères et les stocker dans une chaîne string et non char *.
 
j'ai essayé  

 
pour lire 10 caractères à stocker dans szBuffer, mais même problème que tout à l'heure : sgetn veut un char * comme premier paramètre.
 
Je veux bien utiliser string plutôt que char*, mais je bute systématiquement sur les fonctions à utiliser.
 
Merci pour l'aide...

tu le fais expres ou quoi ? tu peux faire ça avec une string ou alors avec istream::read

Bien sûr que je fais exprès. D'ailleurs je m'étonne que tu aies mis tant de temps à démarrer. On se fait vieux?
Non sérieusement, j'ai bien essayé avec istream::read, mais il veut un char * comme premier argument...

ça change quoi ?
à partir du moment ou tu as la taille, tout va : vecotr, char[]

Je voulais juste rempacer systématiquement mes utilisations de char * et char[] par des strings, mais en effet, dans ce cas précis, il n'y a aucun risque puisque la longueur est connue. Donc dans ce cas là je vais utiliser un char. Je pensais juste que je pouvais systématiquement me passer des char[]. J'avais vu sur un site (me souviens plus lequel) qu'en C++, il fallait éviter les tableaux de char pour représenter les chaînes...

les tableaux sont pas dangereux, sizeof fait bien son travail.

glaurung, je te conseille de lire une bonne FAQ sur le C++, ça t'évitera plein de problèmes de ce genre.
http://www.parashift.com/c++-faq-lite/
(il y a une traduction française, mais elle n'est pas tout à fait à jour)
http://www.cmla.ens-cachan.fr/Util [...] s/C++/FAQ/
Par exemple dans ton cas :
http://www.cmla.ens-cachan.fr/Util [...] AQ/#string
http://www.parashift.com/c++-faq-l [...] l#faq-15.1

 
 
la cat C c'est à coté ...

 
Merci HelloWorld pour cette FAQ qu'il faut rajouter aux références C++ (si ce n'est déjà fait).
Il y a d'ailleurs des réponses à des questions qui reviennent souvent, comme : http://www.parashift.com/c++-faq-l [...] #faq-16.15

 
je veux bien qu'il soit fortement conseillé en c++ d'utiliser std::string plutot que c-style string mais ca doit pas etre non plus une obligation, si on sait ce qu'on fait et qu'on a besoin d'une certaine vitesse d'execution ?

non. c'est stupide comme réflexion. y a des milliards de langages avec un type string (et immutable souvent), on a jamais rien trouvé à redire

 
jvais te dire, les char * ca m'a amené l'inverse. A jamais savoir si je pouvais desallouer un char * ou pas, j'ai un jour terminé avec 20Mo de char * en leaks.  
Ca a sonné leur glas, définitif.

Et quand vous avez une fuite d'eau, vous changez toute la plomberie?

Si un PQ m'irrite les fesses, je change de marque et je jette mon vieux stock
 
on va aller loin avec de telles comparaisons

le char*, c'est beau, c'est bien, c'est efficace et ça roxe en perfs.
 
C'est mieux?

ca roxx en perf, ca roxx en perf, c'est tres vite dit. Et ca donne tellement de cheveux blanc a chaque fois qu'on fait un delete [] / free dessus que ca me semble vraiment un choix peu recommandable.

JE VOUS DEMANDE DE VOUS ARRETER

Quand ton PQ te pique les fesses, tu changes toute la plomberie ?

JE ME TORCHE AVEC LES TUYAUX /O

 
Tout dépend de l'usage qu'on en fait. C'est sûr que si c'est pour faire une flopée de strcat sur sa tronche, mieux vaut se faire une structure, une classe ou un équivalent (mais quand même avec un char* dedans )
 

 
Je ne vois pas de quoi vous parlez.

 
du code de qualité qu'on peut ecrire, genre ce petit exemple, certes debile, mais parlant
 

 
Delete le resultat, delete pas ? ou alors fo tout blinder a coup de strdup(). Facile a dire, mais quand les char * commence a se balader dans l'ensemble d'un programme, ca devient un peu trop festif a mon gout. Je sacrifie a l'aise 5 octets par char * et une poignée de cycle pour laisser ce plaisir la a d'autre, le compilo par ex.
 
 

 
Ah mais ce n'est pas la même chose. Qu'on dise "les char*, je trouve ça peu ragoûtant", je comprends tout à fait. Par contre, "les char*, c'est d'la merde", ça ne passe pas. Je trouve que le premier cas est sincère et que le deuxième est une connerie. Ca me fait penser aux styles d'indentation: on trouve toujours des ayatollahs pour vous expliquer que leur style est le meilleur et que le reste, c'est de la merde.
 
Cela dit, je comprends bien votre exemple mais si on prend toutes les bêtises qu'on peut faire en C/C++ avec chaque instruction, on change de langage (voire de métier)

 
Ah ben ca, je dis pas, et donc de mon point de vue tout ce qu'on peut faire pour supprimer ces points attire-bug du langage est bon a prendre  
 

 
A ce moment-là, il faut supprimer tout ce qui est allocation dynamique (enfin, je veux dire la gestion) et les pointeurs.
 
Et puis l'alcool qui rend saoul
et puis les femmes qui ont des envies de sexe
et aussi les enfants qui hurlent quand ils sont contents
et comme jadis, on brûle à la St-Jean ces foutus chats (qui marchent sur les claviers quand ils veulent des câlins)!
 
pour ma part, ces incarnations du démon m'ont fait faire plus de bugs que les char*...

fo rester raisonnable aussi, hein
 
 
[citation=835043,0,32][nom]DocMaboul a écrit[/nom
et comme jadis, on brûle à la St-Jean ces foutus chats (qui marchent sur les claviers quand ils veulent des câlins)!
[/citation]
 
putain, oué, c relou ca, apres y'a plein de poils dans le clavier, c relou

 
Disons que quand on en a marre de relire/débugger/réécrire pourla dixime fois le code tout pourri des débutants (et des moins débutants) qui utilisent le char* à tout va parce que c'est la seule chose qu'ils ont apprise à l'école, on finit par leur dire simplement : "touche pas à ça, c'est pas pour toi, tu vas encore nous pondre une daube infâme".
Goto aussi c'est rapide, il n'y a pas longtemps encore, je réécrivais du code entièrement fait avec du if...goto. Ca marchait, certes, mais c'est du code de merde, et son auteur peut avoir honte de son boulot qui ne vaut pas un clou.

Perdu!
Les std::string sont souvent plus rapides, et pour une seule et très bonne raison : leur longueur est connues. Donc size() a un tps d'exécution constant, alors que strlen() non.
Sachant qu'il faut faire un strlen pour de strucs genre strcat, etc... DTC les char *.

Pas d'accord ... moi j'ai fait un prog d'analyse de lignes dans un fichier, j'ai fait 2 versions, une avec des char [] l'autre avec des string, j'ai gardé la dernière car plus propre, mais la version avec char est tout de même plus rapide de près de 15-20%

 
et je mettrais un poil de cul à couper qu'un profiler montrerait que cette perte est dûe à des (ré)allocations inutiles mais induites par la facilité de coding.

 
ben si il y a la place DMC pour un char *, il y a aussi la place pour mettre un int, hein

Certainement, en fait il faudrait pouvoir régler la "granularité" (pas sûr que cela soit le bon terme ...), genre, sachant que je traite des lignes, je mettrait une taille de base de 256 octets qui doit suffire dans la majorité des cas, et puis s'il y a besoin de plus ben le système réalloue 256 octets, etc ...

 
Merci HelloWorld, pour cette intéressante lecture en perspective. J'ai pas encore tout lu, mais je cerne déjà un peu mieux la question.