Bon c'est un méchant copier collé très crade, je vous l'accorde mais c'est
seulement pour l'idée. Je pensais qu'en utilisant les templates j'aurais pu
utiliser des strings à la place des char []. Je ne sais pas quelle taille va
faire ma ligne à l'avance ! J'aimerais éviter d'allouer une taille qui sera
soit trop élevée, soit trop faible... et que ça soit dynamique en utilisant
les strings.
Comment faire ? Je vous remercie ! :)
--
TigrouMeow :)
================================
Le site des fournisseurs d'accès :
http://www.fai-fr.com
================================
Ce qui m'a été répondu sur le sujet (je n'étais pas né à l'époque), c'est qu'un des but était d'essayer d'éviter de créer une dépendance entre deux en-têtes de la bibliothèque standard, ce qui me semble personellement une raison assez faible.
Surtout si l'on veut être crédible en disant que le type chaîne de caractères s'écrit en C++ « std::string ». Mais les questions de dépendance constituent un domaine que je ne connais pas trop et qui semble réserver de nombreuses surprises.
--drkm
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
Ce qui m'a été répondu sur le sujet (je n'étais pas né à l'époque),
c'est qu'un des but était d'essayer d'éviter de créer une dépendance
entre deux en-têtes de la bibliothèque standard, ce qui me semble
personellement une raison assez faible.
Surtout si l'on veut être crédible en disant que le type chaîne de
caractères s'écrit en C++ « std::string ». Mais les questions de
dépendance constituent un domaine que je ne connais pas trop et qui
semble réserver de nombreuses surprises.
Ce qui m'a été répondu sur le sujet (je n'étais pas né à l'époque), c'est qu'un des but était d'essayer d'éviter de créer une dépendance entre deux en-têtes de la bibliothèque standard, ce qui me semble personellement une raison assez faible.
Surtout si l'on veut être crédible en disant que le type chaîne de caractères s'écrit en C++ « std::string ». Mais les questions de dépendance constituent un domaine que je ne connais pas trop et qui semble réserver de nombreuses surprises.
--drkm
kanze
Loïc Joly wrote in message news:<416c2981$0$7195$...
drkm wrote:
"Alexandre" writes:
"Fabien LE LEZ" a écrit dans le message de news: >En fait, vraisemblablement pour des raisons historiques, le header ><iostream> ne connaît rien de std::string.
parce qu'il me semble qu'il est plus ancien, non ?
Ben non, ils sont nés ensemble, le 1er septembre 1998. Après une période de gestation plus ou moins longue selon le cas.
C'est plus complexe que ça, en fait. Les <iostream> se basent, plus ou moins, sur les <iostream.h> qui existaient avant. Or, <iostream.h> existait bien avant le premier classe string -- même avant le String de la bibliothèque USL, je crois. En revanche, ce qui est devenu <string> a été une des premières classes définies dans le comité de normalisation. Donc, tous les deux ont une histoire bien avant 1998.
Dans la pratique, on a modifié les <iostream> encore assez tardivement ; je crois qu'ils ne sont devenus des templates qu'après l'adoptation de la STL. À un moment donc où on savait qu'il y aurait un type string dans la norme. Et même si on n'en savait pas encore tous les détails, dire que la fonction peut prendre un std::string n'est pas si difficile que ça.
Je ne vois a priori pas de raison de ne pas avoir surchargé
Ce qui m'a été répondu sur le sujet (je n'étais pas né à l'époque), c'est qu'un des but était d'essayer d'éviter de créer une dépendance entre deux en-têtes de la bibliothèque standard, ce qui me semble personellement une raison assez faible.
<fstream> dépend bien de <istream> et de <ostream>. <istream> et <ostream> dépend bien de <locale> (imbue(), formattage des nombres...). Et <locale> dépend de <string>, dans son operator()(), par exemple. Et finalement, <string> dépend de <istream> et de <ostream>, pour que la boucle soit fermée. (Ce qui doit poser pas mal de problèmes pour celui qui l'implémente -- il s'agit toujours des classes templates, dont l'implémentation doit se rétrouver dans les en-têtes avec les compilateurs courants.)
En fait, on voit clairement qu'il y a eu du rafistollage rapide pour essayer d'arriver à une certaine cohérence après l'adoptation de la STL, sans y arriver. Donc, pour la plupart, <locale> nous exige de travailler avec des char*. Et en fait, il a été « inventé » indépendamment du type string de la norme. Seulement, il y a cette fonction operator()(), qui fait qu'on peut utliser un std::locale comme objet fonctionnel de comparaison dans des fonctions comme std::sort. Je n'y étais pas pour savoir, mais ça crie le rafistollage -- l'ajoute de cette fonction à la dernière minute pour s'aligner sur une contrainte de la STL. <string> souffre du même problème ; aussi tard que la CD2, std::string n'avait pas de fonction push_back, par exemple.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<416c2981$0$7195$8fcfb975@news.wanadoo.fr>...
drkm wrote:
"Alexandre" <alex.g@netcourrier.com> writes:
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news: >En fait, vraisemblablement pour des raisons historiques, le
header ><iostream> ne connaît rien de std::string.
parce qu'il me semble qu'il est plus ancien, non ?
Ben non, ils sont nés ensemble, le 1er septembre 1998. Après une
période de gestation plus ou moins longue selon le cas.
C'est plus complexe que ça, en fait. Les <iostream> se basent, plus ou
moins, sur les <iostream.h> qui existaient avant. Or, <iostream.h>
existait bien avant le premier classe string -- même avant le String de
la bibliothèque USL, je crois. En revanche, ce qui est devenu <string> a
été une des premières classes définies dans le comité de normalisation.
Donc, tous les deux ont une histoire bien avant 1998.
Dans la pratique, on a modifié les <iostream> encore assez tardivement ;
je crois qu'ils ne sont devenus des templates qu'après l'adoptation de
la STL. À un moment donc où on savait qu'il y aurait un type string dans
la norme. Et même si on n'en savait pas encore tous les détails, dire
que la fonction peut prendre un std::string n'est pas si difficile que
ça.
Je ne vois a priori pas de raison de ne pas avoir surchargé
Ce qui m'a été répondu sur le sujet (je n'étais pas né à l'époque),
c'est qu'un des but était d'essayer d'éviter de créer une dépendance
entre deux en-têtes de la bibliothèque standard, ce qui me semble
personellement une raison assez faible.
<fstream> dépend bien de <istream> et de <ostream>. <istream> et
<ostream> dépend bien de <locale> (imbue(), formattage des nombres...).
Et <locale> dépend de <string>, dans son operator()(), par exemple. Et
finalement, <string> dépend de <istream> et de <ostream>, pour que la
boucle soit fermée. (Ce qui doit poser pas mal de problèmes pour celui
qui l'implémente -- il s'agit toujours des classes templates, dont
l'implémentation doit se rétrouver dans les en-têtes avec les
compilateurs courants.)
En fait, on voit clairement qu'il y a eu du rafistollage rapide pour
essayer d'arriver à une certaine cohérence après l'adoptation de la STL,
sans y arriver. Donc, pour la plupart, <locale> nous exige de travailler
avec des char*. Et en fait, il a été « inventé » indépendamment du type
string de la norme. Seulement, il y a cette fonction operator()(), qui
fait qu'on peut utliser un std::locale comme objet fonctionnel de
comparaison dans des fonctions comme std::sort. Je n'y étais pas pour
savoir, mais ça crie le rafistollage -- l'ajoute de cette fonction à la
dernière minute pour s'aligner sur une contrainte de la STL. <string>
souffre du même problème ; aussi tard que la CD2, std::string n'avait
pas de fonction push_back, par exemple.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote in message news:<416c2981$0$7195$...
drkm wrote:
"Alexandre" writes:
"Fabien LE LEZ" a écrit dans le message de news: >En fait, vraisemblablement pour des raisons historiques, le header ><iostream> ne connaît rien de std::string.
parce qu'il me semble qu'il est plus ancien, non ?
Ben non, ils sont nés ensemble, le 1er septembre 1998. Après une période de gestation plus ou moins longue selon le cas.
C'est plus complexe que ça, en fait. Les <iostream> se basent, plus ou moins, sur les <iostream.h> qui existaient avant. Or, <iostream.h> existait bien avant le premier classe string -- même avant le String de la bibliothèque USL, je crois. En revanche, ce qui est devenu <string> a été une des premières classes définies dans le comité de normalisation. Donc, tous les deux ont une histoire bien avant 1998.
Dans la pratique, on a modifié les <iostream> encore assez tardivement ; je crois qu'ils ne sont devenus des templates qu'après l'adoptation de la STL. À un moment donc où on savait qu'il y aurait un type string dans la norme. Et même si on n'en savait pas encore tous les détails, dire que la fonction peut prendre un std::string n'est pas si difficile que ça.
Je ne vois a priori pas de raison de ne pas avoir surchargé
Ce qui m'a été répondu sur le sujet (je n'étais pas né à l'époque), c'est qu'un des but était d'essayer d'éviter de créer une dépendance entre deux en-têtes de la bibliothèque standard, ce qui me semble personellement une raison assez faible.
<fstream> dépend bien de <istream> et de <ostream>. <istream> et <ostream> dépend bien de <locale> (imbue(), formattage des nombres...). Et <locale> dépend de <string>, dans son operator()(), par exemple. Et finalement, <string> dépend de <istream> et de <ostream>, pour que la boucle soit fermée. (Ce qui doit poser pas mal de problèmes pour celui qui l'implémente -- il s'agit toujours des classes templates, dont l'implémentation doit se rétrouver dans les en-têtes avec les compilateurs courants.)
En fait, on voit clairement qu'il y a eu du rafistollage rapide pour essayer d'arriver à une certaine cohérence après l'adoptation de la STL, sans y arriver. Donc, pour la plupart, <locale> nous exige de travailler avec des char*. Et en fait, il a été « inventé » indépendamment du type string de la norme. Seulement, il y a cette fonction operator()(), qui fait qu'on peut utliser un std::locale comme objet fonctionnel de comparaison dans des fonctions comme std::sort. Je n'y étais pas pour savoir, mais ça crie le rafistollage -- l'ajoute de cette fonction à la dernière minute pour s'aligner sur une contrainte de la STL. <string> souffre du même problème ; aussi tard que la CD2, std::string n'avait pas de fonction push_back, par exemple.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
drkm
writes:
Loïc Joly wrote in message news:<416c2981$0$7195$...
drkm wrote:
"Alexandre" writes:
"Fabien LE LEZ" a écrit dans le message de news: >En fait, vraisemblablement pour des raisons historiques, le header ><iostream> ne connaît rien de std::string.
parce qu'il me semble qu'il est plus ancien, non ?
Ben non, ils sont nés ensemble, le 1er septembre 1998. Après une période de gestation plus ou moins longue selon le cas.
C'est plus complexe que ça, en fait. Les <iostream> se basent, plus ou moins, sur les <iostream.h> qui existaient avant. Or, <iostream.h> existait bien avant le premier classe string -- même avant le String de la bibliothèque USL, je crois. En revanche, ce qui est devenu <string> a été une des premières classes définies dans le comité de normalisation. Donc, tous les deux ont une histoire bien avant 1998.
Bien sûr. Mais le fait qu'ils aient une histoire avant septembre 1998 n'empêche pas qu'on aurait pu ajouter un constructeur prenant une std::string en paramètre avant publication.
Dans la pratique, on a modifié les <iostream> encore assez tardivement ; je crois qu'ils ne sont devenus des templates qu'après l'adoptation de la STL. À un moment donc où on savait qu'il y aurait un type string dans la norme. Et même si on n'en savait pas encore tous les détails, dire que la fonction peut prendre un std::string n'est pas si difficile que ça.
Précisément.
Maintenant, je ne connais pas la raison exacte, et ne maîtrise pas assez les questions de dépendances de la SL. Mais dire que la raison est que l'un est plus ancien que l'autre ne me semble pas correct.
--drkm
kanze@gabi-soft.fr writes:
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<416c2981$0$7195$8fcfb975@news.wanadoo.fr>...
drkm wrote:
"Alexandre" <alex.g@netcourrier.com> writes:
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news: >En fait, vraisemblablement pour des raisons historiques, le
header ><iostream> ne connaît rien de std::string.
parce qu'il me semble qu'il est plus ancien, non ?
Ben non, ils sont nés ensemble, le 1er septembre 1998. Après une
période de gestation plus ou moins longue selon le cas.
C'est plus complexe que ça, en fait. Les <iostream> se basent, plus ou
moins, sur les <iostream.h> qui existaient avant. Or, <iostream.h>
existait bien avant le premier classe string -- même avant le String de
la bibliothèque USL, je crois. En revanche, ce qui est devenu <string> a
été une des premières classes définies dans le comité de normalisation.
Donc, tous les deux ont une histoire bien avant 1998.
Bien sûr. Mais le fait qu'ils aient une histoire avant septembre
1998 n'empêche pas qu'on aurait pu ajouter un constructeur prenant une
std::string en paramètre avant publication.
Dans la pratique, on a modifié les <iostream> encore assez tardivement ;
je crois qu'ils ne sont devenus des templates qu'après l'adoptation de
la STL. À un moment donc où on savait qu'il y aurait un type string dans
la norme. Et même si on n'en savait pas encore tous les détails, dire
que la fonction peut prendre un std::string n'est pas si difficile que
ça.
Précisément.
Maintenant, je ne connais pas la raison exacte, et ne maîtrise pas
assez les questions de dépendances de la SL. Mais dire que la raison
est que l'un est plus ancien que l'autre ne me semble pas correct.
Loïc Joly wrote in message news:<416c2981$0$7195$...
drkm wrote:
"Alexandre" writes:
"Fabien LE LEZ" a écrit dans le message de news: >En fait, vraisemblablement pour des raisons historiques, le header ><iostream> ne connaît rien de std::string.
parce qu'il me semble qu'il est plus ancien, non ?
Ben non, ils sont nés ensemble, le 1er septembre 1998. Après une période de gestation plus ou moins longue selon le cas.
C'est plus complexe que ça, en fait. Les <iostream> se basent, plus ou moins, sur les <iostream.h> qui existaient avant. Or, <iostream.h> existait bien avant le premier classe string -- même avant le String de la bibliothèque USL, je crois. En revanche, ce qui est devenu <string> a été une des premières classes définies dans le comité de normalisation. Donc, tous les deux ont une histoire bien avant 1998.
Bien sûr. Mais le fait qu'ils aient une histoire avant septembre 1998 n'empêche pas qu'on aurait pu ajouter un constructeur prenant une std::string en paramètre avant publication.
Dans la pratique, on a modifié les <iostream> encore assez tardivement ; je crois qu'ils ne sont devenus des templates qu'après l'adoptation de la STL. À un moment donc où on savait qu'il y aurait un type string dans la norme. Et même si on n'en savait pas encore tous les détails, dire que la fonction peut prendre un std::string n'est pas si difficile que ça.
Précisément.
Maintenant, je ne connais pas la raison exacte, et ne maîtrise pas assez les questions de dépendances de la SL. Mais dire que la raison est que l'un est plus ancien que l'autre ne me semble pas correct.
--drkm
James Kanze
drkm writes:
[...] |> > Dans la pratique, on a modifié les <iostream> encore assez |> > tardivement ; je crois qu'ils ne sont devenus des templates |> > qu'après l'adoptation de la STL. À un moment donc où on savait |> > qu'il y aurait un type string dans la norme. Et même si on n'en |> > savait pas encore tous les détails, dire que la fonction peut |> > prendre un std::string n'est pas si difficile que ça.
|> Précisément.
|> Maintenant, je ne connais pas la raison exacte, et ne maîtrise pas |> assez les questions de dépendances de la SL. Mais dire que la raison |> est que l'un est plus ancien que l'autre ne me semble pas correct.
Tout à fait.
Je crois (c-à-d qu'il me semble avoir entendu dire, mais que je n'en suis pas du tout certain) que la motivation initiale était bien pour éviter une dépendance circulaire ; que std::string aller dépendre des <iostream>, et donc, que les iostream ne devaient pas dépendre de std::string. Mais si le cas, ils ont raté le coup, probablement à cause d'autres changements qui se faisaient au même temps.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> writes:
[...]
|> > Dans la pratique, on a modifié les <iostream> encore assez
|> > tardivement ; je crois qu'ils ne sont devenus des templates
|> > qu'après l'adoptation de la STL. À un moment donc où on savait
|> > qu'il y aurait un type string dans la norme. Et même si on n'en
|> > savait pas encore tous les détails, dire que la fonction peut
|> > prendre un std::string n'est pas si difficile que ça.
|> Précisément.
|> Maintenant, je ne connais pas la raison exacte, et ne maîtrise pas
|> assez les questions de dépendances de la SL. Mais dire que la raison
|> est que l'un est plus ancien que l'autre ne me semble pas correct.
Tout à fait.
Je crois (c-à-d qu'il me semble avoir entendu dire, mais que je n'en
suis pas du tout certain) que la motivation initiale était bien pour
éviter une dépendance circulaire ; que std::string aller dépendre des
<iostream>, et donc, que les iostream ne devaient pas dépendre de
std::string. Mais si le cas, ils ont raté le coup, probablement à cause
d'autres changements qui se faisaient au même temps.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[...] |> > Dans la pratique, on a modifié les <iostream> encore assez |> > tardivement ; je crois qu'ils ne sont devenus des templates |> > qu'après l'adoptation de la STL. À un moment donc où on savait |> > qu'il y aurait un type string dans la norme. Et même si on n'en |> > savait pas encore tous les détails, dire que la fonction peut |> > prendre un std::string n'est pas si difficile que ça.
|> Précisément.
|> Maintenant, je ne connais pas la raison exacte, et ne maîtrise pas |> assez les questions de dépendances de la SL. Mais dire que la raison |> est que l'un est plus ancien que l'autre ne me semble pas correct.
Tout à fait.
Je crois (c-à-d qu'il me semble avoir entendu dire, mais que je n'en suis pas du tout certain) que la motivation initiale était bien pour éviter une dépendance circulaire ; que std::string aller dépendre des <iostream>, et donc, que les iostream ne devaient pas dépendre de std::string. Mais si le cas, ils ont raté le coup, probablement à cause d'autres changements qui se faisaient au même temps.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
