Bon, je me décide enfin à compléter ma collection de bouquins
C++, histoire de pas poster ici à chaque fois que je redécouvre
la roue et que je me demande s'il vaut mieux lui mettre 8 ou 9
côtés.
Que me conseilleriez vous (vous qui voyez passer mes questions)?
J'ai déjà:
- TC++PL 3ed
- Moderne C++ Design
- The Design and Evolution of C++
Je pensais à:
- Exceptional C++
- Effective C++
- More Exceptional C++ : parce qu'il dit insister sur les traits
et l'usage de la STL
J'hésite sur:
- Essential C++ : je pense que c'est pour des plus débutants
- More Effective C++ : avec les 3 ci dessus, ça devrait
déjà être pas mal
- The Boost Graph Library : je dois faire quelques manips de
base sur les graphes, et je me demande si j'aurais
plus vite fait de tout recoder ou de me plonger dans Boost
Des commentaires ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Disons que C++, c'est un langage *et* une librairie.
Et tu classes ou std::type_info?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Disons que C++, c'est un langage *et* une librairie.
Et tu classes ou std::type_info?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Disons que C++, c'est un langage *et* une librairie.
Et tu classes ou std::type_info?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
Jean-Marc Bourguet wrote:
Marc Boyer writes:
Disons que C++, c'est un langage *et* une librairie.
Et tu classes ou std::type_info?
A) A l'intersection entre le langage et la librairie (j'ai pas parlé de et exclusif). B) L'exception qui confirme la règle ? C) Mon avocat m'interdit de répondre à cette question. D) Le résultat d'un commité de normalisation, ie, un truc bancal, mais le seul compromis que tout le monde était prêt à accepter.
Chacun choisira sa réponse en fonction de sa connaissance du C++, de ses sentiments envers C++, et prendra soin d'argumenter suivant un plan en 2 parties ;-)
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Disons que C++, c'est un langage *et* une librairie.
Et tu classes ou std::type_info?
A) A l'intersection entre le langage et la librairie (j'ai
pas parlé de et exclusif).
B) L'exception qui confirme la règle ?
C) Mon avocat m'interdit de répondre à cette question.
D) Le résultat d'un commité de normalisation, ie, un
truc bancal, mais le seul compromis que tout le monde
était prêt à accepter.
Chacun choisira sa réponse en fonction de sa connaissance
du C++, de ses sentiments envers C++, et prendra soin d'argumenter
suivant un plan en 2 parties ;-)
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Disons que C++, c'est un langage *et* une librairie.
Et tu classes ou std::type_info?
A) A l'intersection entre le langage et la librairie (j'ai pas parlé de et exclusif). B) L'exception qui confirme la règle ? C) Mon avocat m'interdit de répondre à cette question. D) Le résultat d'un commité de normalisation, ie, un truc bancal, mais le seul compromis que tout le monde était prêt à accepter.
Chacun choisira sa réponse en fonction de sa connaissance du C++, de ses sentiments envers C++, et prendra soin d'argumenter suivant un plan en 2 parties ;-)
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer
Jean-Marc Bourguet wrote:
Marc Boyer writes:
Jean-Marc Bourguet wrote: <hs>une ref lisible pour un programmeur qui a fait de l'Ada il y a longtemps, n'a pas l'intention d'en refaire, mais est curieux de savoir ce que ce langage est devenu ?</hs>
Ca donne envie de s'y remettre... Dommage que j'ai pas d'occasion en ce moment (et pas trop l'énergie non plus pour faire ça par pur plaisir).
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Jean-Marc Bourguet wrote:
<hs>une ref lisible pour un programmeur qui a fait de l'Ada
il y a longtemps, n'a pas l'intention d'en refaire, mais
est curieux de savoir ce que ce langage est devenu ?</hs>
Jean-Marc Bourguet wrote: <hs>une ref lisible pour un programmeur qui a fait de l'Ada il y a longtemps, n'a pas l'intention d'en refaire, mais est curieux de savoir ce que ce langage est devenu ?</hs>
Ca donne envie de s'y remettre... Dommage que j'ai pas d'occasion en ce moment (et pas trop l'énergie non plus pour faire ça par pur plaisir).
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Christophe Lephay
Richard Delorme wrote:
A fonctionnalités égales, l'utilisation des string recquiert moins de connaissances que l'utilisation des char[]. Le fait d'en douter serait, IMHA, le signe d'un esprit tourmenté ;) ^^^^^^^^^^^^^^^^
On m'appelle ?
Il y a quand même le problème des « fuites d'abstraction¹ ». Le type string est plus facile à utiliser que char[] (ou char*). Par exemple, avec le type string, le programmeur n'a plus à se soucier à allouer suffisamment d'espace pour stocker une chaîne. C'est fait plus ou moins automatiquement et le bidouillage nécessaire nous est caché. Le type string est une abstraction des char*. Néanmoins, on ne peut pas raisonnablement s'abstenir de la connaissance du type char[] quand on manipule des chaînes en C++. Par exemple, on peut faire :
std::string s = "Salut"; s = s + ", Christophe !";
Mais on ne peut pas faire :
std::string s = "Salut" + ", Christophe !"
parce que les chaînes littérales sont des char[] et que l'opérateur + est défini pour les string, pas pour les char[]. Bref, en C++, il y a toujours un moment où les tableaux de char vous sautent à la figure et l'utilisation des string implique la connaissance des char[].
De quoi je me mêle ? ;)
Chris
Richard Delorme wrote:
A fonctionnalités égales, l'utilisation des string recquiert moins de
connaissances que l'utilisation des char[]. Le fait d'en douter
serait, IMHA, le signe d'un esprit tourmenté ;)
^^^^^^^^^^^^^^^^
On m'appelle ?
Il y a quand même le problème des « fuites d'abstraction¹ ». Le type
string est plus facile à utiliser que char[] (ou char*). Par exemple,
avec le type string, le programmeur n'a plus à se soucier à allouer
suffisamment d'espace pour stocker une chaîne. C'est fait plus ou
moins automatiquement et le bidouillage nécessaire nous est caché. Le
type string est une abstraction des char*.
Néanmoins, on ne peut pas raisonnablement s'abstenir de la
connaissance du type char[] quand on manipule des chaînes en C++. Par
exemple, on peut faire :
std::string s = "Salut";
s = s + ", Christophe !";
Mais on ne peut pas faire :
std::string s = "Salut" + ", Christophe !"
parce que les chaînes littérales sont des char[] et que l'opérateur +
est défini pour les string, pas pour les char[]. Bref, en C++, il y a
toujours un moment où les tableaux de char vous sautent à la figure
et l'utilisation des string implique la connaissance des char[].
A fonctionnalités égales, l'utilisation des string recquiert moins de connaissances que l'utilisation des char[]. Le fait d'en douter serait, IMHA, le signe d'un esprit tourmenté ;) ^^^^^^^^^^^^^^^^
On m'appelle ?
Il y a quand même le problème des « fuites d'abstraction¹ ». Le type string est plus facile à utiliser que char[] (ou char*). Par exemple, avec le type string, le programmeur n'a plus à se soucier à allouer suffisamment d'espace pour stocker une chaîne. C'est fait plus ou moins automatiquement et le bidouillage nécessaire nous est caché. Le type string est une abstraction des char*. Néanmoins, on ne peut pas raisonnablement s'abstenir de la connaissance du type char[] quand on manipule des chaînes en C++. Par exemple, on peut faire :
std::string s = "Salut"; s = s + ", Christophe !";
Mais on ne peut pas faire :
std::string s = "Salut" + ", Christophe !"
parce que les chaînes littérales sont des char[] et que l'opérateur + est défini pour les string, pas pour les char[]. Bref, en C++, il y a toujours un moment où les tableaux de char vous sautent à la figure et l'utilisation des string implique la connaissance des char[].
De quoi je me mêle ? ;)
Chris
Christophe Lephay
Marc Boyer wrote:
Christophe Lephay wrote:
Philippe Guglielmetti wrote:
et que string ne fait PAS partie du langage.
Hum, les strings font bel et bien partie du langage, au même titre que la SL en fait bel et bien partie...
Je dirais plutôt qu'il existe une norme, qui définit conjointement un langage *et* une librairie. Dans DnE, Stroustrup distingue bien le "langage-level" des "library".
D'un autre coté, faire une telle distinction peut être justifiée si on considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu qu'elle le soit en dehors de ce cadre...
Chris
Marc Boyer wrote:
Christophe Lephay wrote:
Philippe Guglielmetti wrote:
et que string ne fait PAS partie du langage.
Hum, les strings font bel et bien partie du langage, au même titre
que la SL en fait bel et bien partie...
Je dirais plutôt qu'il existe une norme, qui définit
conjointement un langage *et* une librairie.
Dans DnE, Stroustrup distingue bien le "langage-level" des
"library".
D'un autre coté, faire une telle distinction peut être justifiée si on
considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu
qu'elle le soit en dehors de ce cadre...
Hum, les strings font bel et bien partie du langage, au même titre que la SL en fait bel et bien partie...
Je dirais plutôt qu'il existe une norme, qui définit conjointement un langage *et* une librairie. Dans DnE, Stroustrup distingue bien le "langage-level" des "library".
D'un autre coté, faire une telle distinction peut être justifiée si on considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu qu'elle le soit en dehors de ce cadre...
Chris
Marc Boyer
Christophe Lephay wrote:
Marc Boyer wrote:
Christophe Lephay wrote:
Philippe Guglielmetti wrote: Je dirais plutôt qu'il existe une norme, qui définit
conjointement un langage *et* une librairie. Dans DnE, Stroustrup distingue bien le "langage-level" des "library".
D'un autre coté, faire une telle distinction peut être justifiée si on considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu qu'elle le soit en dehors de ce cadre...
Ce n'est surement pas justifié dans un développement au jour le jour, mais dans le cadre de ce forum, et plus particulièrement dans le cadre d'une discution sur le partage relatif de la complexité du langage et de la librairie, ou une partie argumente en plus que le langage lui même serait de complexité équivalente à Pascal, ça me semble tout à fait justifié.
Après si on a le temps, on peut discuter aussi de ce qui doit être dans le langage pour permettre à telle ou telle fonctionnalité d'être repoussé dans une librairie ;-)
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Christophe Lephay wrote:
Marc Boyer wrote:
Christophe Lephay wrote:
Philippe Guglielmetti wrote:
Je dirais plutôt qu'il existe une norme, qui définit
conjointement un langage *et* une librairie.
Dans DnE, Stroustrup distingue bien le "langage-level" des
"library".
D'un autre coté, faire une telle distinction peut être justifiée si on
considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu
qu'elle le soit en dehors de ce cadre...
Ce n'est surement pas justifié dans un développement au jour
le jour, mais dans le cadre de ce forum, et plus particulièrement
dans le cadre d'une discution sur le partage relatif de la
complexité du langage et de la librairie, ou une partie
argumente en plus que le langage lui même serait de complexité
équivalente à Pascal, ça me semble tout à fait justifié.
Après si on a le temps, on peut discuter aussi de ce qui
doit être dans le langage pour permettre à telle ou telle
fonctionnalité d'être repoussé dans une librairie ;-)
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Philippe Guglielmetti wrote: Je dirais plutôt qu'il existe une norme, qui définit
conjointement un langage *et* une librairie. Dans DnE, Stroustrup distingue bien le "langage-level" des "library".
D'un autre coté, faire une telle distinction peut être justifiée si on considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu qu'elle le soit en dehors de ce cadre...
Ce n'est surement pas justifié dans un développement au jour le jour, mais dans le cadre de ce forum, et plus particulièrement dans le cadre d'une discution sur le partage relatif de la complexité du langage et de la librairie, ou une partie argumente en plus que le langage lui même serait de complexité équivalente à Pascal, ça me semble tout à fait justifié.
Après si on a le temps, on peut discuter aussi de ce qui doit être dans le langage pour permettre à telle ou telle fonctionnalité d'être repoussé dans une librairie ;-)
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze
Marc Boyer wrote in message news:<bo8hju$lfb$...
Christophe Lephay wrote:
Philippe Guglielmetti wrote:
"Christophe Lephay" a écrit dans le message de news:bo83jf$g6k$
et que string ne fait PAS partie du langage.
Hum, les strings font bel et bien partie du langage, au même titre que la SL en fait bel et bien partie...
Je dirais plutôt qu'il existe une norme, qui définit conjointement un langage *et* une librairie.
C'est ISO 14882: « Programming Languages - C++ ». Qui commence :
This International Standard specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, and so this International Standard also defines C+. Other requirements and relaxations of the first requirement appear at various places within this International Standard.
C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1990 « Programming Languages - C ». In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, inline functions, operator overloading, function name overloading, references, free store management operators, and additional library facilities.
Ça donne bien l'air qu'ils considèrent la bibliothèque comme une partie integrante du langage.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<bo8hju$lfb$1@news.cict.fr>...
Christophe Lephay wrote:
Philippe Guglielmetti wrote:
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message de news:bo83jf$g6k$1@news-reader1.wanadoo.fr...
et que string ne fait PAS partie du langage.
Hum, les strings font bel et bien partie du langage, au même titre
que la SL en fait bel et bien partie...
Je dirais plutôt qu'il existe une norme, qui définit
conjointement un langage *et* une librairie.
C'est ISO 14882: « Programming Languages - C++ ». Qui commence :
This International Standard specifies requirements for
implementations of the C++ programming language. The first such
requirement is that they implement the language, and so this
International Standard also defines C+. Other requirements and
relaxations of the first requirement appear at various places within
this International Standard.
C++ is a general purpose programming language based on the C
programming language as described in ISO/IEC 9899:1990 « Programming
Languages - C ». In addition to the facilities provided by C, C++
provides additional data types, classes, templates, exceptions,
namespaces, inline functions, operator overloading, function name
overloading, references, free store management operators, and
additional library facilities.
Ça donne bien l'air qu'ils considèrent la bibliothèque comme une partie
integrante du langage.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Christophe Lephay" a écrit dans le message de news:bo83jf$g6k$
et que string ne fait PAS partie du langage.
Hum, les strings font bel et bien partie du langage, au même titre que la SL en fait bel et bien partie...
Je dirais plutôt qu'il existe une norme, qui définit conjointement un langage *et* une librairie.
C'est ISO 14882: « Programming Languages - C++ ». Qui commence :
This International Standard specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, and so this International Standard also defines C+. Other requirements and relaxations of the first requirement appear at various places within this International Standard.
C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1990 « Programming Languages - C ». In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, inline functions, operator overloading, function name overloading, references, free store management operators, and additional library facilities.
Ça donne bien l'air qu'ils considèrent la bibliothèque comme une partie integrante du langage.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Loïc Joly
Jean-Marc Bourguet wrote:
Marc Boyer writes:
Disons que C++, c'est un langage *et* une librairie.
Pour moi, C++ est un langage. Il se trouve que ce langage peut être grosso-modo coupé en deux parties, avec une des parties (le "core language") qui n'a presqu'aucune dépendance à la deuxième (la "library") et la deuxième qui peut s'implémenter presqu'entièrement à l'aide du premier.
Et tu classes ou std::type_info?
C'est mon premier "presqu'".
Mon deuxième "presqu'", c'est par exemple <iostream> qui n'est pas implémentable en utilisant directement le langage.
-- Loïc
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Disons que C++, c'est un langage *et* une librairie.
Pour moi, C++ est un langage. Il se trouve que ce langage peut être
grosso-modo coupé en deux parties, avec une des parties (le "core
language") qui n'a presqu'aucune dépendance à la deuxième (la "library")
et la deuxième qui peut s'implémenter presqu'entièrement à l'aide du
premier.
Et tu classes ou std::type_info?
C'est mon premier "presqu'".
Mon deuxième "presqu'", c'est par exemple <iostream> qui n'est pas
implémentable en utilisant directement le langage.
Disons que C++, c'est un langage *et* une librairie.
Pour moi, C++ est un langage. Il se trouve que ce langage peut être grosso-modo coupé en deux parties, avec une des parties (le "core language") qui n'a presqu'aucune dépendance à la deuxième (la "library") et la deuxième qui peut s'implémenter presqu'entièrement à l'aide du premier.
Et tu classes ou std::type_info?
C'est mon premier "presqu'".
Mon deuxième "presqu'", c'est par exemple <iostream> qui n'est pas implémentable en utilisant directement le langage.
-- Loïc
Christophe Lephay
Marc Boyer wrote:
Christophe Lephay wrote:
D'un autre coté, faire une telle distinction peut être justifiée si on considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu qu'elle le soit en dehors de ce cadre...
Ce n'est surement pas justifié dans un développement au jour le jour, mais dans le cadre de ce forum, et plus particulièrement dans le cadre d'une discution sur le partage relatif de la complexité du langage et de la librairie, ou une partie argumente en plus que le langage lui même serait de complexité équivalente à Pascal, ça me semble tout à fait justifié.
En ce qui me concerne, je ne pense pas que la difficulté d'apprentissage du langage soit en quelconque relation avec la SL (ce qui ne veut en aucun cas dire que tout dans la SL soit simple pour autant). De ce point de vue, je trouve cette dicotomie injustifiée.
Mais il semble que je doive apprendre à lire, car j'avais cru comprendre que quelqu'un avait dit que c'est la SL qui rendait C++ difficile d'apprentissage [mauvais esprit(TM)].
En particulier, la SL est moins compliquée à apprendre si on a des connaissances fondamentales, bien qu'un certain nombre de choses pas trop intuitives n'en restent pas moins imputables au langage.
Chris
Marc Boyer wrote:
Christophe Lephay wrote:
D'un autre coté, faire une telle distinction peut être justifiée si
on considère l'objet même de l'ouvrage. Par contre, je ne suis pas
convaincu qu'elle le soit en dehors de ce cadre...
Ce n'est surement pas justifié dans un développement au jour
le jour, mais dans le cadre de ce forum, et plus particulièrement
dans le cadre d'une discution sur le partage relatif de la
complexité du langage et de la librairie, ou une partie
argumente en plus que le langage lui même serait de complexité
équivalente à Pascal, ça me semble tout à fait justifié.
En ce qui me concerne, je ne pense pas que la difficulté d'apprentissage du
langage soit en quelconque relation avec la SL (ce qui ne veut en aucun cas
dire que tout dans la SL soit simple pour autant). De ce point de vue, je
trouve cette dicotomie injustifiée.
Mais il semble que je doive apprendre à lire, car j'avais cru comprendre que
quelqu'un avait dit que c'est la SL qui rendait C++ difficile
d'apprentissage [mauvais esprit(TM)].
En particulier, la SL est moins compliquée à apprendre si on a des
connaissances fondamentales, bien qu'un certain nombre de choses pas trop
intuitives n'en restent pas moins imputables au langage.
D'un autre coté, faire une telle distinction peut être justifiée si on considère l'objet même de l'ouvrage. Par contre, je ne suis pas convaincu qu'elle le soit en dehors de ce cadre...
Ce n'est surement pas justifié dans un développement au jour le jour, mais dans le cadre de ce forum, et plus particulièrement dans le cadre d'une discution sur le partage relatif de la complexité du langage et de la librairie, ou une partie argumente en plus que le langage lui même serait de complexité équivalente à Pascal, ça me semble tout à fait justifié.
En ce qui me concerne, je ne pense pas que la difficulté d'apprentissage du langage soit en quelconque relation avec la SL (ce qui ne veut en aucun cas dire que tout dans la SL soit simple pour autant). De ce point de vue, je trouve cette dicotomie injustifiée.
Mais il semble que je doive apprendre à lire, car j'avais cru comprendre que quelqu'un avait dit que c'est la SL qui rendait C++ difficile d'apprentissage [mauvais esprit(TM)].
En particulier, la SL est moins compliquée à apprendre si on a des connaissances fondamentales, bien qu'un certain nombre de choses pas trop intuitives n'en restent pas moins imputables au langage.
Chris
Michel Michaud
Dans news:3fa7bab4$0$6967$, Richard
Néanmoins, on ne peut pas raisonnablement s'abstenir de la connaissance du type char[] quand on manipule des chaînes en C++. Par exemple, on peut faire :
std::string s = "Salut"; s = s + ", Christophe !";
Mais on ne peut pas faire :
std::string s = "Salut" + ", Christophe !"
Mais on peut faire s= "Salut, Christophe !"; (et = "Salut " "toi !")
Pour un exemple plus réaliste (variante sur un cas vu dans un de mes cours tout juste hier).
Avec string famille="...", prenom="...", nom;
1- Composez nom à partir du nom de famille suivi d'une virgule et un espace, suivi de l'initiale du prénom.
nom= famille + ", " + prenom[0]; // OK...
2- Composez nom à partir de l'initiale du prénom suivi d'un point et un espace, suivi du nom de famille.
nom= prenom[0] + ". " + famille; // Ça compile, mais c'est // incorrect et un // comportement // indéfini ! Horreur !
Je crois qu'une solution générale serait qu'en C++ "..." soit de type std::string et que ces constantes soient convertibles implicitement en const char* au besoin. Pourquoi BS n'y a pas pensé ? J'imagine qu'il y aurait un problème que je ne vois pas :-)
N.B. Il y a évidemment plusieurs bonnes solutions au problème 2 ci-haut, mais la solution présentée « devrait » être correcte et ne l'est pas. Le vrai problème est là...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:3fa7bab4$0$6967$7a628cd7@news.club-internet.fr, Richard
Néanmoins, on ne peut pas raisonnablement s'abstenir de la
connaissance du type char[] quand on manipule des chaînes en C++.
Par exemple, on peut faire :
std::string s = "Salut";
s = s + ", Christophe !";
Mais on ne peut pas faire :
std::string s = "Salut" + ", Christophe !"
Mais on peut faire s= "Salut, Christophe !"; (et = "Salut " "toi !")
Pour un exemple plus réaliste (variante sur un cas vu dans un de mes
cours tout juste hier).
Avec
string famille="...", prenom="...", nom;
1- Composez nom à partir du nom de famille suivi d'une virgule et
un espace, suivi de l'initiale du prénom.
nom= famille + ", " + prenom[0]; // OK...
2- Composez nom à partir de l'initiale du prénom suivi d'un point
et un espace, suivi du nom de famille.
nom= prenom[0] + ". " + famille; // Ça compile, mais c'est
// incorrect et un
// comportement
// indéfini ! Horreur !
Je crois qu'une solution générale serait qu'en C++ "..." soit de
type std::string et que ces constantes soient convertibles
implicitement en const char* au besoin. Pourquoi BS n'y a pas
pensé ? J'imagine qu'il y aurait un problème que je ne vois pas :-)
N.B. Il y a évidemment plusieurs bonnes solutions au problème 2
ci-haut, mais la solution présentée « devrait » être correcte
et ne l'est pas. Le vrai problème est là...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Néanmoins, on ne peut pas raisonnablement s'abstenir de la connaissance du type char[] quand on manipule des chaînes en C++. Par exemple, on peut faire :
std::string s = "Salut"; s = s + ", Christophe !";
Mais on ne peut pas faire :
std::string s = "Salut" + ", Christophe !"
Mais on peut faire s= "Salut, Christophe !"; (et = "Salut " "toi !")
Pour un exemple plus réaliste (variante sur un cas vu dans un de mes cours tout juste hier).
Avec string famille="...", prenom="...", nom;
1- Composez nom à partir du nom de famille suivi d'une virgule et un espace, suivi de l'initiale du prénom.
nom= famille + ", " + prenom[0]; // OK...
2- Composez nom à partir de l'initiale du prénom suivi d'un point et un espace, suivi du nom de famille.
nom= prenom[0] + ". " + famille; // Ça compile, mais c'est // incorrect et un // comportement // indéfini ! Horreur !
Je crois qu'une solution générale serait qu'en C++ "..." soit de type std::string et que ces constantes soient convertibles implicitement en const char* au besoin. Pourquoi BS n'y a pas pensé ? J'imagine qu'il y aurait un problème que je ne vois pas :-)
N.B. Il y a évidemment plusieurs bonnes solutions au problème 2 ci-haut, mais la solution présentée « devrait » être correcte et ne l'est pas. Le vrai problème est là...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
