De la raison de l'utilisation de const char* comme nom de fichier

Salut,

Citation:

---

Envoyé par JolyLoic

<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 :question:

Est-ce dans un soucis de "compatibilité" avec le C :question: (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) :question:

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

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...

Citation:

---

Envoyé par nikko34

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.

Citation:

---

Envoyé par r0d

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).

Citation:

---

Envoyé par r0d

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 *

Citation:

---

Envoyé par r0d

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...

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:

---

1 2 3 4

operator const char* () { return c_str(); }

---

Mais bon :aie:

Citation:

---

Envoyé par poukill

+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:

---

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.