Discussion :

[koala01]

Salut,

<snip>
Pour des raisons avec lesquelles je n'adhère pas, les concepteurs de la bibliothèque standard on voulu limiter le couplage à l'intérieur de celle-ci, et donc ne pas faire dépendre les flux des chaînes de caractères. D'où l'obligation de repasser aux char*.

Je te rassure tout de suite, je ne suis pas partisan d'utiliser des char* nommer les fichiers, mais quelqu'un aurait il en mémoire les raisons qui les ont poussé à prendre cette décision

Est-ce dans un soucis de "compatibilité" avec le C (ce serait surprenant du simple fait des conventions d'appel différentes)

Ou est-ce vraiment "simplement" de ne pas vouloir faire dépendre les classes *fstream de la classe basic_string (quelle qu'en fut la spécialisation)

[nikko34]

pas de compatibilité avec le C mais ne pas obliger l'utilisateur à utiliser des std::string s'il ne veut pas.

[zais_ethael]

Les flux iostream ne seraient-ils pas antérieurs aux autres classes de la stl, std::basic_string compris? Maintenant que j'y pense, ça me semble peu probable vu la dépendance vers un char_traits en argument template, mais j'avais ça en tête...

[r0d]

pas de compatibilité avec le C mais ne pas obliger l'utilisateur à utiliser des std::string s'il ne veut pas.

Dans ce cas, pourquoi ne pas simplement surcharger le constructeur (un avec char*, un autre avec const std::string &) ?

ps: D'autant plus que ce n'est en fait même pas la peine puisque la classe std::string a un constructeur qui prend un char* en paramètre.

[Jean-Marc.Bourguet]

Dans ce cas, pourquoi ne pas simplement surcharger le constructeur (un avec char*, un autre avec const std::string &) ?

C'est fait en C++0X (et si j'ai bonne memoire il y a quelqu'un qui a cherche a identifier tous les endroits de ce genre pour ajouter une telle surcharge).

[JolyLoic]

ps: D'autant plus que ce n'est en fait même pas la peine puisque la classe std::string a un constructeur qui prend un char* en paramètre.

Ce n'aurait pas forcément le même effet, par exemple si l'utilisateur passe en argument une instance d'un type convertible en char const *

[poukill]

ps: D'autant plus que ce n'est en fait même pas la peine puisque la classe std::string a un constructeur qui prend un char* en paramètre.

+1.
Comme le constructeur de std::string n'est pas déclaré "explicit", alors la conversion sera automatique. Le const char * n'a alors plus vraiment lieu d'être...

[Alp]

Mais il n'y aura pas de rétrocompatibilité si l'on ne laisse qu'une version prenant une std::string en argument. A moins qu'ils ajoutent aussi un truc du genre de :

Code :

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

1
2
3
4
operator const char* ()
{
  return c_str();
}

Mais bon

[JolyLoic]

+1.
Comme le constructeur de std::string n'est pas déclaré "explicit", alors la conversion sera automatique. Le const char * n'a alors plus vraiment lieu d'être...

-1

Code :

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

1
2
3
4
5
6
7
class Toto
{
  operator char const *() {return "Toto";}
};
 
Toto toto;
ofstream ofs(toto);

Le code en question marche si une surcharge du constructeur d'ofstream prend un char const * en paramètre, pas s'il n'y en existe qu'une version avec std::string, car le compilateur n'a pas le droit d'utiliser plus d'une conversion définie par l'utilisateur d'affilée, et là 2 seraient nécessaires.