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 :-(
Christophe Lephay wrote: 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.
Oulà, nous avons une divergence sur les méthodes de raisonnement. Si moi aussi je pense que les principales difficultés viennent du "core language", et pas de la stl, je pense que, pour argumenter dans ce sens, il faut savoir distinguer ce qui vient de l'un, ce qui vient de l'autre (et ce qui se trouve au milieu, comme std::type_info...)
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.
Je crois que la STL est, comme le langage, un système qui peut s'apprendre par étapes successives. Pas besoin d'être très avancé pour faire utiliser 'cout<<', ou 'vector<int>'. Pour un 'find_if', il faut avoir un peu avancé. Néanmoins, suivent le conseil de "n'utiliser pas les parties du langage que vous ne maîtriser pas", on peut toujours remplacer le 'find_if' par une boucle, avec un indice 'int i' si on débute, un itérateur si on a avancé.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Christophe Lephay wrote:
Marc Boyer wrote:
Christophe Lephay wrote:
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.
Oulà, nous avons une divergence sur les méthodes de raisonnement.
Si moi aussi je pense que les principales difficultés viennent
du "core language", et pas de la stl, je pense que, pour argumenter
dans ce sens, il faut savoir distinguer ce qui vient de l'un, ce qui
vient de l'autre (et ce qui se trouve au milieu, comme
std::type_info...)
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.
Je crois que la STL est, comme le langage, un système qui peut
s'apprendre par étapes successives.
Pas besoin d'être très avancé pour faire utiliser 'cout<<',
ou 'vector<int>'. Pour un 'find_if', il faut avoir un peu avancé.
Néanmoins, suivent le conseil de "n'utiliser pas les parties
du langage que vous ne maîtriser pas", on peut toujours
remplacer le 'find_if' par une boucle, avec un indice 'int i'
si on débute, un itérateur si on a avancé.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Christophe Lephay wrote: 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.
Oulà, nous avons une divergence sur les méthodes de raisonnement. Si moi aussi je pense que les principales difficultés viennent du "core language", et pas de la stl, je pense que, pour argumenter dans ce sens, il faut savoir distinguer ce qui vient de l'un, ce qui vient de l'autre (et ce qui se trouve au milieu, comme std::type_info...)
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.
Je crois que la STL est, comme le langage, un système qui peut s'apprendre par étapes successives. Pas besoin d'être très avancé pour faire utiliser 'cout<<', ou 'vector<int>'. Pour un 'find_if', il faut avoir un peu avancé. Néanmoins, suivent le conseil de "n'utiliser pas les parties du langage que vous ne maîtriser pas", on peut toujours remplacer le 'find_if' par une boucle, avec un indice 'int i' si on débute, un itérateur si on a avancé.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze
Loïc Joly wrote in message news:<bo8ue8$13m$...
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.
S'implémenter, je ne sais pas. Je dirais plutôt que la deuxième est spécifiée en termes du premier.
Et tu classes ou std::type_info?
C'est mon premier "presqu'".
C'est une classe. Un élément de la bibliothèque, spécifié en termes 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 <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bo8ue8$13m$1@news-reader1.wanadoo.fr>...
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.
S'implémenter, je ne sais pas. Je dirais plutôt que la deuxième est
spécifiée en termes du premier.
Et tu classes ou std::type_info?
C'est mon premier "presqu'".
C'est une classe. Un élément de la bibliothèque, spécifié en termes 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
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.
S'implémenter, je ne sais pas. Je dirais plutôt que la deuxième est spécifiée en termes du premier.
Et tu classes ou std::type_info?
C'est mon premier "presqu'".
C'est une classe. Un élément de la bibliothèque, spécifié en termes 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
Christophe Lephay
Marc Boyer wrote:
Christophe Lephay wrote:
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.
Oulà, nous avons une divergence sur les méthodes de raisonnement. Si moi aussi je pense que les principales difficultés viennent du "core language", et pas de la stl, je pense que, pour argumenter dans ce sens, il faut savoir distinguer ce qui vient de l'un, ce qui vient de l'autre (et ce qui se trouve au milieu, comme std::type_info...)
Hum, je vais reformuler ma pensée, indépendemment de tout ce qui a pu être dit...
Il y a certaines fonctionnalités plus faciles à apprendre que d'autres, indépendemment du fait qu'elles se trouvent dans la SL ou non. Dans le cas de l'apprentissage du langage, je pense que l'utilisation des std::string est plus facile à apprendre que celles des char *.
Le fait que la SL puisse être exprimée en fonction du code langage fait qu'on peut la décrire comme une couche supplémentaire. Un point de vue qui se défend est, qu'à ce titre, elles rajoute de la complexité au langage d'un point de vue quantitatif. Par contre, cette chronologie du design me parait irrelevante dans le cadre de l'apprentissage du langage. En d'autres termes, ce n'est pas parce que std::string est basé sur des char * qu'il est nécessaire d'apprendre les char * avant les string, pas plus que celà implique que les string sont plus dur à apprendre que les char *. Par extension, si la SL ajoute, globalement, de la complexité au langage, celà n'implique pas qu'il faille apprendre le core avant la SL, ni qu'un élément core soit plus difficile à apprendre qu'un élément SL.
Notemment, on peut très bien apprendre à utiliser des string sans connaitre la distinction entre core et SL.
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.
Ce critère de comparaison est valide si on considère qu'une description est d'autant plus longue que la chose décrite est complexe (du reste, arriver à trouver une description simple de quelque chose de complexe a pour effet de lui oter son caractère complexe)...
Chris
Marc Boyer wrote:
Christophe Lephay wrote:
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.
Oulà, nous avons une divergence sur les méthodes de raisonnement.
Si moi aussi je pense que les principales difficultés viennent
du "core language", et pas de la stl, je pense que, pour argumenter
dans ce sens, il faut savoir distinguer ce qui vient de l'un, ce qui
vient de l'autre (et ce qui se trouve au milieu, comme
std::type_info...)
Hum, je vais reformuler ma pensée, indépendemment de tout ce qui a pu être
dit...
Il y a certaines fonctionnalités plus faciles à apprendre que d'autres,
indépendemment du fait qu'elles se trouvent dans la SL ou non. Dans le cas
de l'apprentissage du langage, je pense que l'utilisation des std::string
est plus facile à apprendre que celles des char *.
Le fait que la SL puisse être exprimée en fonction du code langage fait
qu'on peut la décrire comme une couche supplémentaire. Un point de vue qui
se défend est, qu'à ce titre, elles rajoute de la complexité au langage d'un
point de vue quantitatif. Par contre, cette chronologie du design me parait
irrelevante dans le cadre de l'apprentissage du langage. En d'autres termes,
ce n'est pas parce que std::string est basé sur des char * qu'il est
nécessaire d'apprendre les char * avant les string, pas plus que celà
implique que les string sont plus dur à apprendre que les char *. Par
extension, si la SL ajoute, globalement, de la complexité au langage, celà
n'implique pas qu'il faille apprendre le core avant la SL, ni qu'un élément
core soit plus difficile à apprendre qu'un élément SL.
Notemment, on peut très bien apprendre à utiliser des string sans connaitre
la distinction entre core et SL.
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.
Ce critère de comparaison est valide si on considère qu'une description est
d'autant plus longue que la chose décrite est complexe (du reste, arriver à
trouver une description simple de quelque chose de complexe a pour effet de
lui oter son caractère complexe)...
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.
Oulà, nous avons une divergence sur les méthodes de raisonnement. Si moi aussi je pense que les principales difficultés viennent du "core language", et pas de la stl, je pense que, pour argumenter dans ce sens, il faut savoir distinguer ce qui vient de l'un, ce qui vient de l'autre (et ce qui se trouve au milieu, comme std::type_info...)
Hum, je vais reformuler ma pensée, indépendemment de tout ce qui a pu être dit...
Il y a certaines fonctionnalités plus faciles à apprendre que d'autres, indépendemment du fait qu'elles se trouvent dans la SL ou non. Dans le cas de l'apprentissage du langage, je pense que l'utilisation des std::string est plus facile à apprendre que celles des char *.
Le fait que la SL puisse être exprimée en fonction du code langage fait qu'on peut la décrire comme une couche supplémentaire. Un point de vue qui se défend est, qu'à ce titre, elles rajoute de la complexité au langage d'un point de vue quantitatif. Par contre, cette chronologie du design me parait irrelevante dans le cadre de l'apprentissage du langage. En d'autres termes, ce n'est pas parce que std::string est basé sur des char * qu'il est nécessaire d'apprendre les char * avant les string, pas plus que celà implique que les string sont plus dur à apprendre que les char *. Par extension, si la SL ajoute, globalement, de la complexité au langage, celà n'implique pas qu'il faille apprendre le core avant la SL, ni qu'un élément core soit plus difficile à apprendre qu'un élément SL.
Notemment, on peut très bien apprendre à utiliser des string sans connaitre la distinction entre core et SL.
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.
Ce critère de comparaison est valide si on considère qu'une description est d'autant plus longue que la chose décrite est complexe (du reste, arriver à trouver une description simple de quelque chose de complexe a pour effet de lui oter son caractère complexe)...
Chris
Christophe Lephay
Christophe Lephay wrote:
Par extension, si la SL ajoute, globalement, de la complexité au langage, celà n'implique pas qu'il faille apprendre le core avant la SL, ni qu'un élément core soit plus difficile à apprendre qu'un élément SL.
Coquille, il fallait lire : "..., ni qu'un élément core soit plus facile à apprendre qu'un élément SL"
Chris
Christophe Lephay wrote:
Par
extension, si la SL ajoute, globalement, de la complexité au langage,
celà n'implique pas qu'il faille apprendre le core avant la SL, ni
qu'un élément core soit plus difficile à apprendre qu'un élément SL.
Coquille, il fallait lire :
"..., ni
qu'un élément core soit plus facile à apprendre qu'un élément SL"
Par extension, si la SL ajoute, globalement, de la complexité au langage, celà n'implique pas qu'il faille apprendre le core avant la SL, ni qu'un élément core soit plus difficile à apprendre qu'un élément SL.
Coquille, il fallait lire : "..., ni qu'un élément core soit plus facile à apprendre qu'un élément SL"
Chris
Marc Boyer
Christophe Lephay wrote:
Marc Boyer wrote:
Christophe Lephay wrote: Hum, je vais reformuler ma pensée, indépendemment de tout ce qui a pu être
dit...
Je vais pas coter comme un goret: nous sommes d'accord.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Christophe Lephay wrote:
Marc Boyer wrote:
Christophe Lephay wrote:
Hum, je vais reformuler ma pensée, indépendemment de tout ce qui a pu être
dit...
Je vais pas coter comme un goret: nous sommes d'accord.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Christophe Lephay wrote: Hum, je vais reformuler ma pensée, indépendemment de tout ce qui a
pu être dit...
Je vais pas coter comme un goret: nous sommes d'accord.
Je sais :))
Chris
Loïc Joly
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.
-- Loïc
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.
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.
-- Loïc
Gabriel Dos Reis
"Philippe Guglielmetti" writes:
| Bon, ok, la référence à Pascal est un peu réductrice. Mais je me permets de | rappeller que les premiers compilateurs C++ comme Cfront traduisaient du C++ | en C avant de compiler le C.
| Bon, ok, la référence à Pascal est un peu réductrice. Mais je me permets de
| rappeller que les premiers compilateurs C++ comme Cfront traduisaient du C++
| en C avant de compiler le C.
| Bon, ok, la référence à Pascal est un peu réductrice. Mais je me permets de | rappeller que les premiers compilateurs C++ comme Cfront traduisaient du C++ | en C avant de compiler le C.
Et alors ?
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| C++, même au temps de Cfront, apportait des avancées notables, | comme les "public/private", l'appel automatique du destructeur des | variables automatiques en fin de portée, etc.
Yep. Les notion de constructeur/destructreur, portées et contrôle d'accès sont probablement les apports majeurs de C++-1.0 par rapport à C. Il est instructif de voir comment cela a mis du temps avant de percer.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| C++, même au temps de Cfront, apportait des avancées notables,
| comme les "public/private", l'appel automatique du destructeur des
| variables automatiques en fin de portée, etc.
Yep. Les notion de constructeur/destructreur, portées et contrôle
d'accès sont probablement les apports majeurs de C++-1.0 par rapport à
C. Il est instructif de voir comment cela a mis du temps avant de
percer.
| C++, même au temps de Cfront, apportait des avancées notables, | comme les "public/private", l'appel automatique du destructeur des | variables automatiques en fin de portée, etc.
Yep. Les notion de constructeur/destructreur, portées et contrôle d'accès sont probablement les apports majeurs de C++-1.0 par rapport à C. Il est instructif de voir comment cela a mis du temps avant de percer.
-- Gaby
Gabriel Dos Reis
Loïc Joly writes:
| 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.
C'est un peu comme on quand on mesure la productivité d'un informaticien en termes de nombre de lignes de code écrites.
-- Gaby
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| 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.
C'est un peu comme on quand on mesure la productivité d'un
informaticien en termes de nombre de lignes de code écrites.
| 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.
C'est un peu comme on quand on mesure la productivité d'un informaticien en termes de nombre de lignes de code écrites.
