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 :-(
| Ça donne bien l'air qu'ils considèrent la bibliothèque comme une partie | integrante du langage.
Yep. Je suis toujours amusé quand les gens veulent faire une distinction nette entre langage et bibliothèque C++. Le C++ forme un tout. Il y a une partie de la bibliothèque qui est optionelle pour un freestanding mais même dans ce cas, il y a quand même une partie des chapitres 18 et 19.
-- Gaby
kanze@gabi-soft.fr writes:
| Ça donne bien l'air qu'ils considèrent la bibliothèque comme une partie
| integrante du langage.
Yep. Je suis toujours amusé quand les gens veulent faire une
distinction nette entre langage et bibliothèque C++. Le C++ forme un
tout. Il y a une partie de la bibliothèque qui est optionelle pour un
freestanding mais même dans ce cas, il y a quand même une partie des
chapitres 18 et 19.
| Ça donne bien l'air qu'ils considèrent la bibliothèque comme une partie | integrante du langage.
Yep. Je suis toujours amusé quand les gens veulent faire une distinction nette entre langage et bibliothèque C++. Le C++ forme un tout. Il y a une partie de la bibliothèque qui est optionelle pour un freestanding mais même dans ce cas, il y a quand même une partie des chapitres 18 et 19.
-- Gaby
Gabriel Dos Reis
Richard Delorme writes:
| Mais on ne peut pas faire : | | std::string s = "Salut" + ", Christophe !"
mais on peut écrire
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[].
mais ce moment peut être différé au plus tard possible,
-- Gaby
Richard Delorme <abulmo@nospam.fr> writes:
| Mais on ne peut pas faire :
|
| std::string s = "Salut" + ", Christophe !"
mais on peut écrire
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[].
mais ce moment peut être différé au plus tard possible,
| Mais on ne peut pas faire : | | std::string s = "Salut" + ", Christophe !"
mais on peut écrire
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[].
mais ce moment peut être différé au plus tard possible,
-- Gaby
kanze
"Michel Michaud" wrote in message news:<hiZpb.18793$...
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 :-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la compatibilité C ?
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à...
Il y a plusieurs « vrais problèmes ». Pour commencer, le fait que prenom[0] + ". " soit légal. Mais la compatibilité avec C n'est pas sans un certain coût.
-- 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
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<hiZpb.18793$mB5.626317@news20.bellglobal.com>...
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 :-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la
compatibilité C ?
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à...
Il y a plusieurs « vrais problèmes ». Pour commencer, le fait que
prenom[0] + ". " soit légal. Mais la compatibilité avec C n'est pas sans
un certain coût.
--
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
"Michel Michaud" wrote in message news:<hiZpb.18793$...
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 :-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la compatibilité C ?
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à...
Il y a plusieurs « vrais problèmes ». Pour commencer, le fait que prenom[0] + ". " soit légal. Mais la compatibilité avec C n'est pas sans un certain coût.
-- 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
Christophe Lephay
Loïc Joly wrote:
Christophe Lephay wrote:
Un élément relativement objectif permettant de mesurer les complexités relatives du core language et de la SL serait de comparer les pages qui y sont respectivement consacrées dans la norme. Je n'ai jamais eu la norme sous les yeux, mais je mettrais ma main (la gauche, on sait jamais), que la description du core prend plus de place que la description de la SL.
Core : 325 pages. SL : 341 pages.
Mais je ne crois pas que ce soit une mesure de complexité appropriée.
Je suis d'accord dans la mesure où elle ne va pas dans mon sens ;)
Mais c'est toujours une indication, même si une mesure plus précise prendrait en compte les références croisées, comme étant autant d'indices d'un manque de modularité... :)
Chris
Loïc Joly wrote:
Christophe Lephay wrote:
Un élément relativement objectif permettant de mesurer les
complexités relatives du core language et de la SL serait de
comparer les pages qui y sont respectivement consacrées dans la
norme. Je n'ai jamais eu la norme sous les yeux, mais je mettrais ma
main (la gauche, on sait jamais), que la description du core prend
plus de place que la description de la SL.
Core : 325 pages.
SL : 341 pages.
Mais je ne crois pas que ce soit une mesure de complexité appropriée.
Je suis d'accord dans la mesure où elle ne va pas dans mon sens ;)
Mais c'est toujours une indication, même si une mesure plus précise
prendrait en compte les références croisées, comme étant autant d'indices
d'un manque de modularité... :)
Un élément relativement objectif permettant de mesurer les complexités relatives du core language et de la SL serait de comparer les pages qui y sont respectivement consacrées dans la norme. Je n'ai jamais eu la norme sous les yeux, mais je mettrais ma main (la gauche, on sait jamais), que la description du core prend plus de place que la description de la SL.
Core : 325 pages. SL : 341 pages.
Mais je ne crois pas que ce soit une mesure de complexité appropriée.
Je suis d'accord dans la mesure où elle ne va pas dans mon sens ;)
Mais c'est toujours une indication, même si une mesure plus précise prendrait en compte les références croisées, comme étant autant d'indices d'un manque de modularité... :)
Chris
Gabriel Dos Reis
writes:
[...]
| > 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 :-) | | J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la | compatibilité C ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
-- Gaby
kanze@gabi-soft.fr writes:
[...]
| > 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 :-)
|
| J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la
| compatibilité C ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
| > 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 :-) | | J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la | compatibilité C ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
-- Gaby
kanze
Gabriel Dos Reis wrote in message news:...
writes:
[...]
| > 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 | > :-)
| J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la | compatibilité C ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
Il y a des dégrées de compatibilité.
Il y a une longue histoire. Je ne sais pas quand la première classe de chaîne est apparue, mais le langage lui-même n'en a pas depuis très longtemps. Et si Stroustrup n'a pas créer un type intégré string depuis le début, j'imagine que les raisons de compatibilité avec C jouait un rôle (mais le mieux serait de lui le démander, si on tient réelement à savoir).
Maintenant, évidemment, indépendamment du C, on a le problème de la compatibilité avec le C++ existant ; je veux bien écouter des propositions, mais je suis scéptique qu'on puisse faire quelque chose de vraiment utile sans casser trop le code existant.
-- 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
Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
news:<flad793g07.fsf@sel.cmla.ens-cachan.fr>...
kanze@gabi-soft.fr writes:
[...]
| > 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
| > :-)
| J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la
| compatibilité C ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
Il y a des dégrées de compatibilité.
Il y a une longue histoire. Je ne sais pas quand la première classe de
chaîne est apparue, mais le langage lui-même n'en a pas depuis très
longtemps. Et si Stroustrup n'a pas créer un type intégré string depuis
le début, j'imagine que les raisons de compatibilité avec C jouait un
rôle (mais le mieux serait de lui le démander, si on tient réelement à
savoir).
Maintenant, évidemment, indépendamment du C, on a le problème de la
compatibilité avec le C++ existant ; je veux bien écouter des
propositions, mais je suis scéptique qu'on puisse faire quelque chose de
vraiment utile sans casser trop le code existant.
--
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
| > 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 | > :-)
| J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la | compatibilité C ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
Il y a des dégrées de compatibilité.
Il y a une longue histoire. Je ne sais pas quand la première classe de chaîne est apparue, mais le langage lui-même n'en a pas depuis très longtemps. Et si Stroustrup n'a pas créer un type intégré string depuis le début, j'imagine que les raisons de compatibilité avec C jouait un rôle (mais le mieux serait de lui le démander, si on tient réelement à savoir).
Maintenant, évidemment, indépendamment du C, on a le problème de la compatibilité avec le C++ existant ; je veux bien écouter des propositions, mais je suis scéptique qu'on puisse faire quelque chose de vraiment utile sans casser trop le code existant.
-- 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
Michel Michaud
Dans news:, Gabriel Dos
writes:
[...]
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 :-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la compatibilité C ?
Je ne vois pas ce message de James. Alors je pose ma question ici. James, tu as un exemple d'incompatibilité qui serait brisée par ma proposition ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
Inutile d'en ajouter (c'est ce que j'essaie de proposer).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:flad793g07.fsf@sel.cmla.ens-cachan.fr, Gabriel Dos
kanze@gabi-soft.fr writes:
[...]
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
:-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la
compatibilité C ?
Je ne vois pas ce message de James. Alors je pose ma question ici.
James, tu as un exemple d'incompatibilité qui serait brisée par ma
proposition ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
Inutile d'en ajouter (c'est ce que j'essaie de proposer).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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 :-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la compatibilité C ?
Je ne vois pas ce message de James. Alors je pose ma question ici. James, tu as un exemple d'incompatibilité qui serait brisée par ma proposition ?
ah, parce que la compatibilité C n'est pas déjà cassée ?
Inutile d'en ajouter (c'est ce que j'essaie de proposer).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > [...] | | > | > 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 | > | > :-) | | > | J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la | > | compatibilité C ? | | > ah, parce que la compatibilité C n'est pas déjà cassée ? | | Il y a des dégrées de compatibilité. | | Il y a une longue histoire. Je ne sais pas quand la première classe de | chaîne est apparue, mais le langage lui-même n'en a pas depuis très | longtemps. Et si Stroustrup n'a pas créer un type intégré string depuis | le début, j'imagine que les raisons de compatibilité avec C jouait un | rôle (mais le mieux serait de lui le démander, si on tient réelement à | savoir).
Je ne doute pas une seule seconde que l'option de type std::string intégré au langage ait été considérée. Seulement, je doute que la compatibilité avec le C ait été le facteur déterminant de son rejet.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
| news:<flad793g07.fsf@sel.cmla.ens-cachan.fr>...
| > kanze@gabi-soft.fr writes:
|
| > [...]
|
| > | > 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
| > | > :-)
|
| > | J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la
| > | compatibilité C ?
|
| > ah, parce que la compatibilité C n'est pas déjà cassée ?
|
| Il y a des dégrées de compatibilité.
|
| Il y a une longue histoire. Je ne sais pas quand la première classe de
| chaîne est apparue, mais le langage lui-même n'en a pas depuis très
| longtemps. Et si Stroustrup n'a pas créer un type intégré string depuis
| le début, j'imagine que les raisons de compatibilité avec C jouait un
| rôle (mais le mieux serait de lui le démander, si on tient réelement à
| savoir).
Je ne doute pas une seule seconde que l'option de type std::string
intégré au langage ait été considérée. Seulement, je doute que la
compatibilité avec le C ait été le facteur déterminant de son rejet.
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > [...] | | > | > 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 | > | > :-) | | > | J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la | > | compatibilité C ? | | > ah, parce que la compatibilité C n'est pas déjà cassée ? | | Il y a des dégrées de compatibilité. | | Il y a une longue histoire. Je ne sais pas quand la première classe de | chaîne est apparue, mais le langage lui-même n'en a pas depuis très | longtemps. Et si Stroustrup n'a pas créer un type intégré string depuis | le début, j'imagine que les raisons de compatibilité avec C jouait un | rôle (mais le mieux serait de lui le démander, si on tient réelement à | savoir).
Je ne doute pas une seule seconde que l'option de type std::string intégré au langage ait été considérée. Seulement, je doute que la compatibilité avec le C ait été le facteur déterminant de son rejet.
-- Gaby
kanze
"Michel Michaud" wrote in message news:<xQsqb.6577$...
Dans news:, Gabriel Dos
writes:
[...]
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 :-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la compatibilité C ?
Je ne vois pas ce message de James. Alors je pose ma question ici. James, tu as un exemple d'incompatibilité qui serait brisée par ma proposition ?
Je n'ai pas étudié ta proposition en détail, mais je pensais plutôt aux débuts : en C, quelque chose comme "..." à une signification bien déterminée, et on aurait considéré qu'un tel changement s'en éloigner de trop.
-- 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
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<xQsqb.6577$Pg1.387781@news20.bellglobal.com>...
Dans news:flad793g07.fsf@sel.cmla.ens-cachan.fr, Gabriel Dos
kanze@gabi-soft.fr writes:
[...]
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
:-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la
compatibilité C ?
Je ne vois pas ce message de James. Alors je pose ma question ici.
James, tu as un exemple d'incompatibilité qui serait brisée par ma
proposition ?
Je n'ai pas étudié ta proposition en détail, mais je pensais plutôt aux
débuts : en C, quelque chose comme "..." à une signification bien
déterminée, et on aurait considéré qu'un tel changement s'en éloigner de
trop.
--
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
"Michel Michaud" wrote in message news:<xQsqb.6577$...
Dans news:, Gabriel Dos
writes:
[...]
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 :-)
J'imagine qu'il y avait pensé. Mais comment est-ce que tu résous la compatibilité C ?
Je ne vois pas ce message de James. Alors je pose ma question ici. James, tu as un exemple d'incompatibilité qui serait brisée par ma proposition ?
Je n'ai pas étudié ta proposition en détail, mais je pensais plutôt aux débuts : en C, quelque chose comme "..." à une signification bien déterminée, et on aurait considéré qu'un tel changement s'en éloigner de trop.
-- 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
