J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait
std::string .
Pourquoi donc?
A part le fait que chaque librairie utilise son propre type CString,
QString ... et que du coup ça fait moche d'utiliser std::string.
| J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait | std::string . | Pourquoi donc?
C'est comme tous les compromis : tout le monde est satisfait, mais personne n'est content.
-- Gaby
James Kanze
JBB wrote:
J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait std::string .
Pourquoi donc?
C'est une conception plutôt baclée, et pas du tout propre. L'interface rend une implémentation efficace, particulièrement dans un milieu multithreaded, impossible. L'ensemble de fonctions fait que c'est un mélange de plusieurs conceptes -- parfois on traite en termes d'itérateurs, parfois en termes de première indice/longueur. En somme, elle est tout sauf une belle conception.
Ceci dit, elle fonctionne pour la plupart des utilisations. Et elle est standard. Ce qui fait que ...
A part le fait que chaque librairie utilise son propre type CString, QString ... et que du coup ça fait moche d'utiliser std::string.
c'est précisement la motivation pour n'utiliser que std::string. Partout.
En ce qui concerne le nombre de chaînes défini dans les autres bibliothèques : il faut dire que la norme a trainé beaucoup à sortir. Ce qui a fait que les autres bibliothèques étaient bien obligées à définir leur propre type de chaîne. Qu'il sont obligé encore à supporter, évidemment, pour des raisons de compatibilité avec la passée. On pourrait espérer néaumoins que dans une future très proche, elles doublent toutes leurs interfaces avec leurs chaînes par une avec std::string. (On pourrait espérer, mais alors... Pourquoi est-ce qu'elles ont attendu déjà si longtemps.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
JBB wrote:
J'ai lu dans ce forum (je retrouve plus ou) que personne
n'aimait std::string .
Pourquoi donc?
C'est une conception plutôt baclée, et pas du tout propre.
L'interface rend une implémentation efficace, particulièrement
dans un milieu multithreaded, impossible. L'ensemble de
fonctions fait que c'est un mélange de plusieurs conceptes --
parfois on traite en termes d'itérateurs, parfois en termes de
première indice/longueur. En somme, elle est tout sauf une belle
conception.
Ceci dit, elle fonctionne pour la plupart des utilisations. Et
elle est standard. Ce qui fait que ...
A part le fait que chaque librairie utilise son propre type
CString, QString ... et que du coup ça fait moche d'utiliser
std::string.
c'est précisement la motivation pour n'utiliser que std::string.
Partout.
En ce qui concerne le nombre de chaînes défini dans les autres
bibliothèques : il faut dire que la norme a trainé beaucoup à
sortir. Ce qui a fait que les autres bibliothèques étaient bien
obligées à définir leur propre type de chaîne. Qu'il sont obligé
encore à supporter, évidemment, pour des raisons de
compatibilité avec la passée. On pourrait espérer néaumoins que
dans une future très proche, elles doublent toutes leurs
interfaces avec leurs chaînes par une avec std::string. (On
pourrait espérer, mais alors... Pourquoi est-ce qu'elles ont
attendu déjà si longtemps.)
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait std::string .
Pourquoi donc?
C'est une conception plutôt baclée, et pas du tout propre. L'interface rend une implémentation efficace, particulièrement dans un milieu multithreaded, impossible. L'ensemble de fonctions fait que c'est un mélange de plusieurs conceptes -- parfois on traite en termes d'itérateurs, parfois en termes de première indice/longueur. En somme, elle est tout sauf une belle conception.
Ceci dit, elle fonctionne pour la plupart des utilisations. Et elle est standard. Ce qui fait que ...
A part le fait que chaque librairie utilise son propre type CString, QString ... et que du coup ça fait moche d'utiliser std::string.
c'est précisement la motivation pour n'utiliser que std::string. Partout.
En ce qui concerne le nombre de chaînes défini dans les autres bibliothèques : il faut dire que la norme a trainé beaucoup à sortir. Ce qui a fait que les autres bibliothèques étaient bien obligées à définir leur propre type de chaîne. Qu'il sont obligé encore à supporter, évidemment, pour des raisons de compatibilité avec la passée. On pourrait espérer néaumoins que dans une future très proche, elles doublent toutes leurs interfaces avec leurs chaînes par une avec std::string. (On pourrait espérer, mais alors... Pourquoi est-ce qu'elles ont attendu déjà si longtemps.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Gabriel Dos Reis wrote:
JBB writes:
| J'ai lu dans ce forum (je retrouve plus ou) que personne | n'aimait std::string . Pourquoi donc?
C'est comme tous les compromis : tout le monde est satisfait, mais personne n'est content.
Dans le cas de std::string, je crois que même satisfait est une exagération. Disons que sauf cas exceptionnel, elle n'est pas assez mauvaise pour justifier l'utilisation de quelque chose de non standard.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
JBB <merci@pasdespam.fr> writes:
| J'ai lu dans ce forum (je retrouve plus ou) que personne
| n'aimait std::string . Pourquoi donc?
C'est comme tous les compromis : tout le monde est satisfait, mais
personne n'est content.
Dans le cas de std::string, je crois que même satisfait est une
exagération. Disons que sauf cas exceptionnel, elle n'est pas
assez mauvaise pour justifier l'utilisation de quelque chose de
non standard.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
| J'ai lu dans ce forum (je retrouve plus ou) que personne | n'aimait std::string . Pourquoi donc?
C'est comme tous les compromis : tout le monde est satisfait, mais personne n'est content.
Dans le cas de std::string, je crois que même satisfait est une exagération. Disons que sauf cas exceptionnel, elle n'est pas assez mauvaise pour justifier l'utilisation de quelque chose de non standard.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gabriel Dos Reis
James Kanze writes:
| JBB wrote: | > J'ai lu dans ce forum (je retrouve plus ou) que personne | > n'aimait std::string . | | > Pourquoi donc? | | C'est une conception plutôt baclée, et pas du tout propre.
Je ne suis pas sûr d'être d'accord avec le qualificatif « baclée. » Certainement, elle fait partie des classes les plus vielles de la biliothèque (en comptant les ancêtres). Chacun a voulu y voir sa propre conception de chaîne de caractères.
string s; assert(s[s.size()] == 0);
les gens qui ont fait ça ont pris leur temps ;-)
-- Gaby
James Kanze <kanze@none> writes:
| JBB wrote:
| > J'ai lu dans ce forum (je retrouve plus ou) que personne
| > n'aimait std::string .
|
| > Pourquoi donc?
|
| C'est une conception plutôt baclée, et pas du tout propre.
Je ne suis pas sûr d'être d'accord avec le qualificatif « baclée. »
Certainement, elle fait partie des classes les plus vielles de la
biliothèque (en comptant les ancêtres). Chacun a voulu y voir sa
propre conception de chaîne de caractères.
| JBB wrote: | > J'ai lu dans ce forum (je retrouve plus ou) que personne | > n'aimait std::string . | | > Pourquoi donc? | | C'est une conception plutôt baclée, et pas du tout propre.
Je ne suis pas sûr d'être d'accord avec le qualificatif « baclée. » Certainement, elle fait partie des classes les plus vielles de la biliothèque (en comptant les ancêtres). Chacun a voulu y voir sa propre conception de chaîne de caractères.
string s; assert(s[s.size()] == 0);
les gens qui ont fait ça ont pris leur temps ;-)
-- Gaby
Michel Michaud
Dans le message 42ce57e5$0$28673$,
J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait std::string .
J'aime bien std::string... (il est facile de trouver des raisons)
Pourquoi donc?
Je crois que l'expression anglaise est « everything and the kitchen sink ». D'autres auraient préféré des chaînes immuables pour en permettre une utilisation plus facile dans les programmes multi-fils.
A part le fait que chaque librairie utilise son propre type CString,QString ... et que du coup ça fait moche d'utiliser std::string.
En fait, c'est une raison pour employer std::string partout où l'on peut et de ne faire que les transformations dans un autre type au dernier moment, tout ça afin d'ajouter un peu de portabilité. Ceci dit, je ne sais pas si c'est très courant...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 42ce57e5$0$28673$626a14ce@news.free.fr,
J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait
std::string .
J'aime bien std::string... (il est facile de trouver des raisons)
Pourquoi donc?
Je crois que l'expression anglaise est « everything and the
kitchen sink ». D'autres auraient préféré des chaînes immuables
pour en permettre une utilisation plus facile dans les programmes
multi-fils.
A part le fait que chaque librairie utilise son propre type
CString,QString ... et que du coup ça fait moche d'utiliser
std::string.
En fait, c'est une raison pour employer std::string partout où
l'on peut et de ne faire que les transformations dans un autre
type au dernier moment, tout ça afin d'ajouter un peu de
portabilité. Ceci dit, je ne sais pas si c'est très courant...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait std::string .
J'aime bien std::string... (il est facile de trouver des raisons)
Pourquoi donc?
Je crois que l'expression anglaise est « everything and the kitchen sink ». D'autres auraient préféré des chaînes immuables pour en permettre une utilisation plus facile dans les programmes multi-fils.
A part le fait que chaque librairie utilise son propre type CString,QString ... et que du coup ça fait moche d'utiliser std::string.
En fait, c'est une raison pour employer std::string partout où l'on peut et de ne faire que les transformations dans un autre type au dernier moment, tout ça afin d'ajouter un peu de portabilité. Ceci dit, je ne sais pas si c'est très courant...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Fabien LE LEZ
On Sat, 9 Jul 2005 13:09:54 -0400, "Michel Michaud" :
Je crois que l'expression anglaise est « everything and the kitchen sink ».
C'est marrant, tu emploies une expression anglaise ici (J'imagine que c'est l'équivalent de "le beurre et l'argent du beurre" ?)...
D'autres auraient préféré des chaînes immuables pour en permettre une utilisation plus facile dans les programmes
multi-fils.
... et paradoxalement, une traduction littérale ici (J'ai mis un petit moment à la décrypter, celle-là...)
On Sat, 9 Jul 2005 13:09:54 -0400, "Michel Michaud" <mm@gdzid.com>:
Je crois que l'expression anglaise est « everything and the
kitchen sink ».
C'est marrant, tu emploies une expression anglaise ici (J'imagine que
c'est l'équivalent de "le beurre et l'argent du beurre" ?)...
D'autres auraient préféré des chaînes immuables
pour en permettre une utilisation plus facile dans les programmes
multi-fils.
... et paradoxalement, une traduction littérale ici (J'ai mis un petit
moment à la décrypter, celle-là...)
C'est marrant, tu emploies une expression anglaise ici (J'imagine que c'est l'équivalent de "le beurre et l'argent du beurre" ?)...
Je ne connais pas l'équivalent français... Et celle que tu proposes n'est pas la bonne (cette autre expression existe aussi en anglais).
Sous la forme « Have your cake and eat it too » si je ne me trompe.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Fabien LE LEZ
On Sat, 9 Jul 2005 14:05:36 -0400, "Michel Michaud" :
Tu connais une autre traduction ?
Non, mais je connais une autre solution : puisque de toutes façons il faut ajouter un mot à la langue française pour parler de ce concept, autant utiliser le mot "multithread", au moins on comprend tout de suite.
Enfin bon, tout ça n'est qu'une répétition de la même discussion... l'Atlantique est trop large pour qu'on se mette d'accord.
On Sat, 9 Jul 2005 14:05:36 -0400, "Michel Michaud" <mm@gdzid.com>:
Tu connais une autre traduction ?
Non, mais je connais une autre solution : puisque de toutes façons il
faut ajouter un mot à la langue française pour parler de ce concept,
autant utiliser le mot "multithread", au moins on comprend tout de
suite.
Enfin bon, tout ça n'est qu'une répétition de la même discussion...
l'Atlantique est trop large pour qu'on se mette d'accord.
On Sat, 9 Jul 2005 14:05:36 -0400, "Michel Michaud" :
Tu connais une autre traduction ?
Non, mais je connais une autre solution : puisque de toutes façons il faut ajouter un mot à la langue française pour parler de ce concept, autant utiliser le mot "multithread", au moins on comprend tout de suite.
Enfin bon, tout ça n'est qu'une répétition de la même discussion... l'Atlantique est trop large pour qu'on se mette d'accord.
Michel Michaud
Dans le message ,
On Sat, 9 Jul 2005 14:05:36 -0400, "Michel Michaud" :
Tu connais une autre traduction ?
Non, mais je connais une autre solution : puisque de toutes façons il faut ajouter un mot à la langue française pour parler de ce concept, autant utiliser le mot "multithread", au moins on comprend tout de suite.
On comprend tout de suite quand on sait ce qu'est multithread. D'un autre côté, pense à des débutants qui ne connaissent pas tous les concepts. Dirais-tu loop au lieu de boucle, parameter au lieu de paramètre, etc. Ça n'aiderait personne.
Pour quelqu'un qui connait la terminologie anglaise et qui parle anglais, il est effectivement inutile de parler français ou de faire des livres en français. Pour les autres, il faut expliquer les concepts de façon compréhensible (en français) et il est certainement utile de faire connaître les termes anglais. Mais je peux t'assurer que mes élèves n'auront pas plus de facilité à apprendre la programmation multithread si j'utilise le mot anglais :-)
Enfin bon, tout ça n'est qu'une répétition de la même discussion... l'Atlantique est trop large pour qu'on se mette d'accord.
Je ne vois pas pourquoi...
En fait, j'ajouterais que la traduction d'une expression mot peut le faire s'améliorer : l'exemple classique est interblocage qui est beaucoup plus « autoexplicatif » que deadlock. Et je suis certain qu'il y a d'autres exemples...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message gt50d159h88gh6offk3q147rc642mogq2c@4ax.com,
On Sat, 9 Jul 2005 14:05:36 -0400, "Michel Michaud" <mm@gdzid.com>:
Tu connais une autre traduction ?
Non, mais je connais une autre solution : puisque de toutes façons
il faut ajouter un mot à la langue française pour parler de ce
concept, autant utiliser le mot "multithread", au moins on comprend
tout de suite.
On comprend tout de suite quand on sait ce qu'est multithread.
D'un autre côté, pense à des débutants qui ne connaissent pas tous
les concepts. Dirais-tu loop au lieu de boucle, parameter au lieu
de paramètre, etc. Ça n'aiderait personne.
Pour quelqu'un qui connait la terminologie anglaise et qui parle
anglais, il est effectivement inutile de parler français ou de
faire des livres en français. Pour les autres, il faut expliquer
les concepts de façon compréhensible (en français) et il est
certainement utile de faire connaître les termes anglais. Mais
je peux t'assurer que mes élèves n'auront pas plus de facilité
à apprendre la programmation multithread si j'utilise le mot
anglais :-)
Enfin bon, tout ça n'est qu'une répétition de la même discussion...
l'Atlantique est trop large pour qu'on se mette d'accord.
Je ne vois pas pourquoi...
En fait, j'ajouterais que la traduction d'une expression mot peut
le faire s'améliorer : l'exemple classique est interblocage qui
est beaucoup plus « autoexplicatif » que deadlock. Et je suis
certain qu'il y a d'autres exemples...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
On Sat, 9 Jul 2005 14:05:36 -0400, "Michel Michaud" :
Tu connais une autre traduction ?
Non, mais je connais une autre solution : puisque de toutes façons il faut ajouter un mot à la langue française pour parler de ce concept, autant utiliser le mot "multithread", au moins on comprend tout de suite.
On comprend tout de suite quand on sait ce qu'est multithread. D'un autre côté, pense à des débutants qui ne connaissent pas tous les concepts. Dirais-tu loop au lieu de boucle, parameter au lieu de paramètre, etc. Ça n'aiderait personne.
Pour quelqu'un qui connait la terminologie anglaise et qui parle anglais, il est effectivement inutile de parler français ou de faire des livres en français. Pour les autres, il faut expliquer les concepts de façon compréhensible (en français) et il est certainement utile de faire connaître les termes anglais. Mais je peux t'assurer que mes élèves n'auront pas plus de facilité à apprendre la programmation multithread si j'utilise le mot anglais :-)
Enfin bon, tout ça n'est qu'une répétition de la même discussion... l'Atlantique est trop large pour qu'on se mette d'accord.
Je ne vois pas pourquoi...
En fait, j'ajouterais que la traduction d'une expression mot peut le faire s'améliorer : l'exemple classique est interblocage qui est beaucoup plus « autoexplicatif » que deadlock. Et je suis certain qu'il y a d'autres exemples...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
