Version imprimable
Bonjour,
Je voi souvent que les personnes exp�riment�es du forum conseil d'utiliser le std::string au lieu du char.
Mais alors pourquoi la m�thode write de ofstream n'admet pas un type std::string ?
J'ai du utiliser la m�thode .c_str() pour transformer mon string en char, mais est-ce que �a r�duit beaucoup les performances cette m�thode?
Merci d'avance...
J'en sais rien mais j'ai vu �a sur la FAQ qui r�pondra peut etre en parti � ta question:
http://c.developpez.com/faq/cpp/?pag...TRINGS_lenteur
La r�ponse la plus couremment cit�e est qu'� l'origine, les diff�rentes parties de la ST �taient consid�r�es comme un peu ind�pendantes (et avaient �t� d�velopp�es par des gens diff�rents), et les gens ne voulaient pas imposer aux utilisateur de iostream de devoir inclure le fichier string, pour des raisons de temps de compilation, et d'ind�pendance entre les diff�rentes parties de la biblioth�que. D�j� que string d�pend de iostream, une d�pendance dans l'autre sens aurait rendu le tout circulaire, ce qui n'est pas tr�s beau selon certains crit�res.
A mon avis, il s'agit d'une erreur, qui j'esp�re sera r�par�e dans une prochaine version de la norme (il y a de bonnes chances), avec �ventuellement des choses plus adapt�es pour manier des chemins que ne peut l'�tre une b�te string, comme la classe path que l'on trouve dans boost::filtesystem.
Pour la supposition d'impact sur les perfs, je n'y crois pas :
- D�j�, quand on parle d'acc�s au disque dur, je suis persuad� que si impact il y a, il est totalement n�gligeable par rapport au temps de traitement global.
- De plus rien n'aurait emp�ch� de fournir les deux versions, avec char* et std::string, et ce afin de faire plaisir � tout le monde.
Accessoirement, write est con�ue pour s�rializer des buffers d'octets, pas des chaines de caract�res.
Tu n'as qu'� utiliser std::vector<char>