je suis tombé sur un bug subtil, il y a quelques jours où le code ressemblait à ceci:À quoi servent les «fins» ces jours-ci?
ostringstream ss;
int anInt(7);
ss << anInt << "HABITS";
ss << ends;
string theWholeLot = ss.str();
Le problème était que la ends
collait un « \ 0 » dans le ostringstream
si theWholeLot
ressemblait réellement "7HABITS\0"
(par exemple une valeur nulle à la fin)
maintenant, cela n'a pas démontré parce que theWholeLot
a ensuite été utilisé pour prendre la partie en utilisant const char *
string::c_str()
cela signifiait que le nul était masqué comme il est devenu juste un delimiter. Toutefois, lorsque cela a changé d'utiliser des chaînes tout au long, l'hypothèse nulle signifie quelque chose et tout à coup des comparaisons telles que:
if (theWholeLot == "7HABITS")
échouerait. Cela m'a fait penser: Vraisemblablement la raison pour ends
est un retour aux jours de ostrstream
quand le flux n'était normalement pas terminé avec un null et devait être ainsi que str()
(qui a ensuite chassé pas un string
mais un char *
) fonctionnerait correctement .
Cependant, maintenant qu'il est impossible de jeter un char *
d'un ostringstream
, en utilisant ends
est non seulement superflue, mais potentiellement dangereux et je considère les enlever tout de mon code clients.
Quelqu'un peut-il voir une raison évidente d'utiliser ends
dans un environnement std::string
seulement?
Mon seul problème serait quel est l'environnement std :: string? Tout programme non trivial va aux arguments char * system call, etc. Cela dit, il y a une demi-douzaine d'autres façons de traiter cela et la fin a une utilité négligeable. – Duck
Voici une utilisation de 'std :: ends': http://stackoverflow.com/questions/624260/how-to-reuse-an-ostringstream/624291#624291 –
Ce n'est pas seulement pour les chaînes. C'est utile pour les flux généraux. Certains outils Unix ont besoin d'octets NULL comme terminateurs. 'cout << se termine;' les fournira. –