Merci à vous pour vos premiers retours.Ça n'avait déjà plus aucun sens en 2000.
Certes, connaître les structures for, if, etc., peut faire gagner du
temps lors de l'apprentissage de C++, mais pour ça, Javascript
convient largement aussi bien que C.Non cela n'a pas vraiment de sens. C'est même un facteur de confusion
car les étudiants ou même les professionnels (ou leurs managers...)
peuvent croire, de ce fait, que C++ n'est qu'une extension de C (comme
certains clients qui me réclamaient des cours de C++ de 3 jours car
leurs troupes connaissaient déjà le langage C !).
Personnellement, je suis aussi de cet avis.
Aujourd'hui encore, il est courant de faire face à l'idée reçue
« Le C++, c'est du C avec quelques fonctionnalitées en plus, c'est
du C amélioré, il faut donc d'abord apprendre le C si l'on veut
apprendre le C++ ».
C'est, toujours selon moi, non seulement une perte de temps
(parce que le C non plus n'est pas un langage _si_ simple),
mais en plus cela peut devenir totalement contre-productif. Certaines
habitudes venues du C peuvent conduire à de mauvaises habitudes
en C++ (et certainement inversement), comme l'utilisation abusive de
char *, le passage par valeur créant des copies inutiles. Bref, si
l'objectif est d'apprendre le C++, qui, comme il est souvent répété,
est un langage à part entière, et non pas pas une « extension »
du C, pourquoi ne pas directement commencer par du C++ ?
Nous sommes donc d'accord sur ce point là.J'ai, par ailleurs enseigné à la fois dans un mastère
de génie logiciel et dans l'industrie pour des cours en
intra et en inter entreprise. J'ai commencé à enseigner le C++
en 1991 et cette année, j'ai encore donné un cours de C++
avancé abordant la métaprogrammation, les traits, les
politiques, CRTP (Curiously Recurring Template Pattern),
Substitution Failure Is Not An Error (SFINAE), etc.
Je vois, tu as donc de la bouteille comme on dit :)
Car ce que tu cites effectivement, on ne le trouve pas
dans un cours de C++ mais en général en s'intéressant un
peu plus au langage, sur différentes ressources en ligne
ou dans des bouquins plus avancés.Il fut une époque où j'ai vu apparaître la STL alors
que je donnais, en entreprise, des cours d'une semaine de
C++ environ toutes les 6 semaines. C'était très difficile
car il fallait en parler mais pas en détail. Il fallait
dire juste ce qu'il faut pour que les participants puissent
"faire leur chemin" ensuite. C'est ça le plus difficile
pédagogiquement parlant.
Désormais, la STL est bel et bien ancrée et implémentée par
les compilateurs. Dans les années 1990, je ne dis pas, mais
le langage a été normalisé pour la première fois en 1998,
il s'en est donc passé du temps depuis. Comme disait Herb Sutter
ou Scott Meyers (je ne m'en rappelle plus), le standard C++
comporte deux éléments :
- Les règles du langage (grammaire, ...)
- La bibliothèque standard (SL, STL)
On comprend donc que la bibliothèque standard fait parti
intégrante du langage et de sa spécification. Aujourd'hui,
en 2011, je ne comprends donc pas comment un cours peut
ne pas comporter une partie complète sur la STL, alors
que c'est un élément aussi important que le langage en
lui-même (tu n'es pas d'accord avec ce que disait Scott,
mais ça je ne pense pas qu'on puisse réellement le nier).
Pourtant, de nombreux cours ne se content uniquement
« d'aborder » la STL, dans un module en fin de cours.
Dans mon école, la STL est considérée comme un « complément ».
De mon avis, aujourd'hui, on ne peut pas se prétendre
développeur C++ sans connaître la STL, ses conteneurs,
ses algorithmes et ses itérateurs au moins un minimum
(je ne dis pas non plus connaitre tous les détails d'implémentation).
Il me semble qu'il ne faut pas "maximiser" les nouveautés
de C++11. Elles doivent s'inscrire naturellement dans un
cours comme l'uniformisation des syntaxes d'initialisation.
Cependant, il faut faire attention à qui l'on s'adresse car
pour des professionnels, ils ne passeront pas du jour au lendemain
à C++11. Il faut donc continuer à décrire les anciennes syntaxes.
Par contre, dans l'enseignement académique, on peut y aller plus
franchement, si je puis dire.Par contre, il faut en parler dans les cursus universitaires et,
dans l'immédiat, je laisserais plutôt le cours classique et je
ferais un chapitre de survol, à part, sur les nouveautés et, au
fur et à mesure, que les nouveautés se répandent, les intégrer dans
le cours. Certaines se propageront plus vite que d'autres. De toutes
façon, les librairies concernant le multithreading, ne doivent pas
être abordées dans un tronc commun, il me semble.
Pour ma part, je vais rester dans le domaine académique (j'y fais parti,
en tant qu'étudiant). Donc, si je te comprends bien, tu n'intègrerais
pas le nouveau standard C++11 dans le cours « principal » mais dans
un espèce de module annexe ? Puis au fur et à mesure de l'adoption
de ses nouvelles pratiques, tu transfèrerais petit à petit le tout
dans le cours principal ? Pour tout ce qui concerne la concurrence
et le multithreading, je suis d'accord pour que cela figure dans un
cours à part, et non pas dans un cours de C++ même.
Personnellement, je commencerais dès à présent à intégrer certaines
fonctionnalités présentes dans le nouveau standard, et qui sont
communément implémentées dans la majorité des compilateurs
(auto, lambdas, nullptr, ...). Et je pense que je présenterais
utiles à connaitre, pour le côté « développement de bibliothèques »,
comme les rvalues references & move semantics.
Les bouquins viendront vite, à mon avis, mais il y a tellement de
mauvais livres sur C++ (et la programmation, en général...).
Et c'est bien dommage. Mais malgré tout, il y a, en contrepartie,
de très bon ouvrages (j'aime bien la série des Effective C++,
que tu sembles un peu moins apprécier, ou encore la série
des Exceptionnal C++).
Le mieux c'est d'utiliser Internet. Il y a déjà des
choses intéressantes sur les nouveautés comme,
par exemple, sur le multithreading (et ça date de 2008 !) :
http://www.devx.com/SpecialReports/Article/38883/0/page/1
De toute façon, Internet regorge de ressources. Mais là encore,
il faut utiliser les bonnes ressources. On peut aussi y trouver
de nombreux enregistrements de conférences ou tout simplement
de « cours », comme sur channel9.
Pour le multithreading en C++, il y a le bouquin
d'Anthony Williams, ou bien la série de vidéos de Bartosz Milewski
: http://www.corensic.com/Learn.aspx
Merci à vous pour vos premiers retours.
Ça n'avait déjà plus aucun sens en 2000.
Certes, connaître les structures for, if, etc., peut faire gagner du
temps lors de l'apprentissage de C++, mais pour ça, Javascript
convient largement aussi bien que C.
Non cela n'a pas vraiment de sens. C'est même un facteur de confusion
car les étudiants ou même les professionnels (ou leurs managers...)
peuvent croire, de ce fait, que C++ n'est qu'une extension de C (comme
certains clients qui me réclamaient des cours de C++ de 3 jours car
leurs troupes connaissaient déjà le langage C !).
Personnellement, je suis aussi de cet avis.
Aujourd'hui encore, il est courant de faire face à l'idée reçue
« Le C++, c'est du C avec quelques fonctionnalitées en plus, c'est
du C amélioré, il faut donc d'abord apprendre le C si l'on veut
apprendre le C++ ».
C'est, toujours selon moi, non seulement une perte de temps
(parce que le C non plus n'est pas un langage _si_ simple),
mais en plus cela peut devenir totalement contre-productif. Certaines
habitudes venues du C peuvent conduire à de mauvaises habitudes
en C++ (et certainement inversement), comme l'utilisation abusive de
char *, le passage par valeur créant des copies inutiles. Bref, si
l'objectif est d'apprendre le C++, qui, comme il est souvent répété,
est un langage à part entière, et non pas pas une « extension »
du C, pourquoi ne pas directement commencer par du C++ ?
Nous sommes donc d'accord sur ce point là.
J'ai, par ailleurs enseigné à la fois dans un mastère
de génie logiciel et dans l'industrie pour des cours en
intra et en inter entreprise. J'ai commencé à enseigner le C++
en 1991 et cette année, j'ai encore donné un cours de C++
avancé abordant la métaprogrammation, les traits, les
politiques, CRTP (Curiously Recurring Template Pattern),
Substitution Failure Is Not An Error (SFINAE), etc.
Je vois, tu as donc de la bouteille comme on dit :)
Car ce que tu cites effectivement, on ne le trouve pas
dans un cours de C++ mais en général en s'intéressant un
peu plus au langage, sur différentes ressources en ligne
ou dans des bouquins plus avancés.
Il fut une époque où j'ai vu apparaître la STL alors
que je donnais, en entreprise, des cours d'une semaine de
C++ environ toutes les 6 semaines. C'était très difficile
car il fallait en parler mais pas en détail. Il fallait
dire juste ce qu'il faut pour que les participants puissent
"faire leur chemin" ensuite. C'est ça le plus difficile
pédagogiquement parlant.
Désormais, la STL est bel et bien ancrée et implémentée par
les compilateurs. Dans les années 1990, je ne dis pas, mais
le langage a été normalisé pour la première fois en 1998,
il s'en est donc passé du temps depuis. Comme disait Herb Sutter
ou Scott Meyers (je ne m'en rappelle plus), le standard C++
comporte deux éléments :
- Les règles du langage (grammaire, ...)
- La bibliothèque standard (SL, STL)
On comprend donc que la bibliothèque standard fait parti
intégrante du langage et de sa spécification. Aujourd'hui,
en 2011, je ne comprends donc pas comment un cours peut
ne pas comporter une partie complète sur la STL, alors
que c'est un élément aussi important que le langage en
lui-même (tu n'es pas d'accord avec ce que disait Scott,
mais ça je ne pense pas qu'on puisse réellement le nier).
Pourtant, de nombreux cours ne se content uniquement
« d'aborder » la STL, dans un module en fin de cours.
Dans mon école, la STL est considérée comme un « complément ».
De mon avis, aujourd'hui, on ne peut pas se prétendre
développeur C++ sans connaître la STL, ses conteneurs,
ses algorithmes et ses itérateurs au moins un minimum
(je ne dis pas non plus connaitre tous les détails d'implémentation).
Il me semble qu'il ne faut pas "maximiser" les nouveautés
de C++11. Elles doivent s'inscrire naturellement dans un
cours comme l'uniformisation des syntaxes d'initialisation.
Cependant, il faut faire attention à qui l'on s'adresse car
pour des professionnels, ils ne passeront pas du jour au lendemain
à C++11. Il faut donc continuer à décrire les anciennes syntaxes.
Par contre, dans l'enseignement académique, on peut y aller plus
franchement, si je puis dire.
Par contre, il faut en parler dans les cursus universitaires et,
dans l'immédiat, je laisserais plutôt le cours classique et je
ferais un chapitre de survol, à part, sur les nouveautés et, au
fur et à mesure, que les nouveautés se répandent, les intégrer dans
le cours. Certaines se propageront plus vite que d'autres. De toutes
façon, les librairies concernant le multithreading, ne doivent pas
être abordées dans un tronc commun, il me semble.
Pour ma part, je vais rester dans le domaine académique (j'y fais parti,
en tant qu'étudiant). Donc, si je te comprends bien, tu n'intègrerais
pas le nouveau standard C++11 dans le cours « principal » mais dans
un espèce de module annexe ? Puis au fur et à mesure de l'adoption
de ses nouvelles pratiques, tu transfèrerais petit à petit le tout
dans le cours principal ? Pour tout ce qui concerne la concurrence
et le multithreading, je suis d'accord pour que cela figure dans un
cours à part, et non pas dans un cours de C++ même.
Personnellement, je commencerais dès à présent à intégrer certaines
fonctionnalités présentes dans le nouveau standard, et qui sont
communément implémentées dans la majorité des compilateurs
(auto, lambdas, nullptr, ...). Et je pense que je présenterais
utiles à connaitre, pour le côté « développement de bibliothèques »,
comme les rvalues references & move semantics.
Les bouquins viendront vite, à mon avis, mais il y a tellement de
mauvais livres sur C++ (et la programmation, en général...).
Et c'est bien dommage. Mais malgré tout, il y a, en contrepartie,
de très bon ouvrages (j'aime bien la série des Effective C++,
que tu sembles un peu moins apprécier, ou encore la série
des Exceptionnal C++).
Le mieux c'est d'utiliser Internet. Il y a déjà des
choses intéressantes sur les nouveautés comme,
par exemple, sur le multithreading (et ça date de 2008 !) :
http://www.devx.com/SpecialReports/Article/38883/0/page/1
De toute façon, Internet regorge de ressources. Mais là encore,
il faut utiliser les bonnes ressources. On peut aussi y trouver
de nombreux enregistrements de conférences ou tout simplement
de « cours », comme sur channel9.
Pour le multithreading en C++, il y a le bouquin
d'Anthony Williams, ou bien la série de vidéos de Bartosz Milewski
: http://www.corensic.com/Learn.aspx
Merci à vous pour vos premiers retours.Ça n'avait déjà plus aucun sens en 2000.
Certes, connaître les structures for, if, etc., peut faire gagner du
temps lors de l'apprentissage de C++, mais pour ça, Javascript
convient largement aussi bien que C.Non cela n'a pas vraiment de sens. C'est même un facteur de confusion
car les étudiants ou même les professionnels (ou leurs managers...)
peuvent croire, de ce fait, que C++ n'est qu'une extension de C (comme
certains clients qui me réclamaient des cours de C++ de 3 jours car
leurs troupes connaissaient déjà le langage C !).
Personnellement, je suis aussi de cet avis.
Aujourd'hui encore, il est courant de faire face à l'idée reçue
« Le C++, c'est du C avec quelques fonctionnalitées en plus, c'est
du C amélioré, il faut donc d'abord apprendre le C si l'on veut
apprendre le C++ ».
C'est, toujours selon moi, non seulement une perte de temps
(parce que le C non plus n'est pas un langage _si_ simple),
mais en plus cela peut devenir totalement contre-productif. Certaines
habitudes venues du C peuvent conduire à de mauvaises habitudes
en C++ (et certainement inversement), comme l'utilisation abusive de
char *, le passage par valeur créant des copies inutiles. Bref, si
l'objectif est d'apprendre le C++, qui, comme il est souvent répété,
est un langage à part entière, et non pas pas une « extension »
du C, pourquoi ne pas directement commencer par du C++ ?
Nous sommes donc d'accord sur ce point là.J'ai, par ailleurs enseigné à la fois dans un mastère
de génie logiciel et dans l'industrie pour des cours en
intra et en inter entreprise. J'ai commencé à enseigner le C++
en 1991 et cette année, j'ai encore donné un cours de C++
avancé abordant la métaprogrammation, les traits, les
politiques, CRTP (Curiously Recurring Template Pattern),
Substitution Failure Is Not An Error (SFINAE), etc.
Je vois, tu as donc de la bouteille comme on dit :)
Car ce que tu cites effectivement, on ne le trouve pas
dans un cours de C++ mais en général en s'intéressant un
peu plus au langage, sur différentes ressources en ligne
ou dans des bouquins plus avancés.Il fut une époque où j'ai vu apparaître la STL alors
que je donnais, en entreprise, des cours d'une semaine de
C++ environ toutes les 6 semaines. C'était très difficile
car il fallait en parler mais pas en détail. Il fallait
dire juste ce qu'il faut pour que les participants puissent
"faire leur chemin" ensuite. C'est ça le plus difficile
pédagogiquement parlant.
Désormais, la STL est bel et bien ancrée et implémentée par
les compilateurs. Dans les années 1990, je ne dis pas, mais
le langage a été normalisé pour la première fois en 1998,
il s'en est donc passé du temps depuis. Comme disait Herb Sutter
ou Scott Meyers (je ne m'en rappelle plus), le standard C++
comporte deux éléments :
- Les règles du langage (grammaire, ...)
- La bibliothèque standard (SL, STL)
On comprend donc que la bibliothèque standard fait parti
intégrante du langage et de sa spécification. Aujourd'hui,
en 2011, je ne comprends donc pas comment un cours peut
ne pas comporter une partie complète sur la STL, alors
que c'est un élément aussi important que le langage en
lui-même (tu n'es pas d'accord avec ce que disait Scott,
mais ça je ne pense pas qu'on puisse réellement le nier).
Pourtant, de nombreux cours ne se content uniquement
« d'aborder » la STL, dans un module en fin de cours.
Dans mon école, la STL est considérée comme un « complément ».
De mon avis, aujourd'hui, on ne peut pas se prétendre
développeur C++ sans connaître la STL, ses conteneurs,
ses algorithmes et ses itérateurs au moins un minimum
(je ne dis pas non plus connaitre tous les détails d'implémentation).
Il me semble qu'il ne faut pas "maximiser" les nouveautés
de C++11. Elles doivent s'inscrire naturellement dans un
cours comme l'uniformisation des syntaxes d'initialisation.
Cependant, il faut faire attention à qui l'on s'adresse car
pour des professionnels, ils ne passeront pas du jour au lendemain
à C++11. Il faut donc continuer à décrire les anciennes syntaxes.
Par contre, dans l'enseignement académique, on peut y aller plus
franchement, si je puis dire.Par contre, il faut en parler dans les cursus universitaires et,
dans l'immédiat, je laisserais plutôt le cours classique et je
ferais un chapitre de survol, à part, sur les nouveautés et, au
fur et à mesure, que les nouveautés se répandent, les intégrer dans
le cours. Certaines se propageront plus vite que d'autres. De toutes
façon, les librairies concernant le multithreading, ne doivent pas
être abordées dans un tronc commun, il me semble.
Pour ma part, je vais rester dans le domaine académique (j'y fais parti,
en tant qu'étudiant). Donc, si je te comprends bien, tu n'intègrerais
pas le nouveau standard C++11 dans le cours « principal » mais dans
un espèce de module annexe ? Puis au fur et à mesure de l'adoption
de ses nouvelles pratiques, tu transfèrerais petit à petit le tout
dans le cours principal ? Pour tout ce qui concerne la concurrence
et le multithreading, je suis d'accord pour que cela figure dans un
cours à part, et non pas dans un cours de C++ même.
Personnellement, je commencerais dès à présent à intégrer certaines
fonctionnalités présentes dans le nouveau standard, et qui sont
communément implémentées dans la majorité des compilateurs
(auto, lambdas, nullptr, ...). Et je pense que je présenterais
utiles à connaitre, pour le côté « développement de bibliothèques »,
comme les rvalues references & move semantics.
Les bouquins viendront vite, à mon avis, mais il y a tellement de
mauvais livres sur C++ (et la programmation, en général...).
Et c'est bien dommage. Mais malgré tout, il y a, en contrepartie,
de très bon ouvrages (j'aime bien la série des Effective C++,
que tu sembles un peu moins apprécier, ou encore la série
des Exceptionnal C++).
Le mieux c'est d'utiliser Internet. Il y a déjà des
choses intéressantes sur les nouveautés comme,
par exemple, sur le multithreading (et ça date de 2008 !) :
http://www.devx.com/SpecialReports/Article/38883/0/page/1
De toute façon, Internet regorge de ressources. Mais là encore,
il faut utiliser les bonnes ressources. On peut aussi y trouver
de nombreux enregistrements de conférences ou tout simplement
de « cours », comme sur channel9.
Pour le multithreading en C++, il y a le bouquin
d'Anthony Williams, ou bien la série de vidéos de Bartosz Milewski
: http://www.corensic.com/Learn.aspx
Ils sont persuadés que c'est du C dans lequel
"malloc" s'écrit "new".
En fait, je ne vois pas trop comment parler de new sans introduire
un malloc() à un moment ou un autre.
À l'extrème limite, un cours de C++ devrait être un cours de
programmation objet indépendant de tout langage
C'est un peu pareil dans tous les langages. J'ai cherché récemment
un bouquin de référence sur les nouveautés de Fortran 2003 (même pas
2008) et j'ai eu un peu peur. Je n'en ai trouvé qu'un seul...
Ils sont persuadés que c'est du C dans lequel
"malloc" s'écrit "new".
En fait, je ne vois pas trop comment parler de new sans introduire
un malloc() à un moment ou un autre.
À l'extrème limite, un cours de C++ devrait être un cours de
programmation objet indépendant de tout langage
C'est un peu pareil dans tous les langages. J'ai cherché récemment
un bouquin de référence sur les nouveautés de Fortran 2003 (même pas
2008) et j'ai eu un peu peur. Je n'en ai trouvé qu'un seul...
Ils sont persuadés que c'est du C dans lequel
"malloc" s'écrit "new".
En fait, je ne vois pas trop comment parler de new sans introduire
un malloc() à un moment ou un autre.
À l'extrème limite, un cours de C++ devrait être un cours de
programmation objet indépendant de tout langage
C'est un peu pareil dans tous les langages. J'ai cherché récemment
un bouquin de référence sur les nouveautés de Fortran 2003 (même pas
2008) et j'ai eu un peu peur. Je n'en ai trouvé qu'un seul...
Le Wed, 14 Dec 2011 09:20:15 +0100,
Wykaaa écrivait :Fabien LE LEZ a écrit :On Wed, 14 Dec 2011 01:04:43 +0100, Wykaaa :J'ai vu un programme ou, en transformant tous les passages par valeurs
en références constante, on a gagné presque 30% en temps d'exécution !
Ça me paraît beaucoup. Quel compilateur utilisais-tu ?
Je crois qu'il s'agissait du compilateur d'IBM sous AIX au milieu des
années 90, mais là n'est pas le problème, il me semble. Peux-tu me citer
UN compilateur qui transforme les passage par valeur en référence
constante ?
DEC C++, au moins sur VMS en version VAX. Qu'est-ce que je gagne ?
Le Wed, 14 Dec 2011 09:20:15 +0100,
Wykaaa <wykaaa@yahoo.fr> écrivait :
Fabien LE LEZ a écrit :
On Wed, 14 Dec 2011 01:04:43 +0100, Wykaaa <wykaaa@yahoo.fr>:
J'ai vu un programme ou, en transformant tous les passages par valeurs
en références constante, on a gagné presque 30% en temps d'exécution !
Ça me paraît beaucoup. Quel compilateur utilisais-tu ?
Je crois qu'il s'agissait du compilateur d'IBM sous AIX au milieu des
années 90, mais là n'est pas le problème, il me semble. Peux-tu me citer
UN compilateur qui transforme les passage par valeur en référence
constante ?
DEC C++, au moins sur VMS en version VAX. Qu'est-ce que je gagne ?
Le Wed, 14 Dec 2011 09:20:15 +0100,
Wykaaa écrivait :Fabien LE LEZ a écrit :On Wed, 14 Dec 2011 01:04:43 +0100, Wykaaa :J'ai vu un programme ou, en transformant tous les passages par valeurs
en références constante, on a gagné presque 30% en temps d'exécution !
Ça me paraît beaucoup. Quel compilateur utilisais-tu ?
Je crois qu'il s'agissait du compilateur d'IBM sous AIX au milieu des
années 90, mais là n'est pas le problème, il me semble. Peux-tu me citer
UN compilateur qui transforme les passage par valeur en référence
constante ?
DEC C++, au moins sur VMS en version VAX. Qu'est-ce que je gagne ?
On Wed, 14 Dec 2011 06:51:48 +0000 (UTC), JKB
:Ils sont persuadés que c'est du C dans lequel
"malloc" s'écrit "new".
En fait, je ne vois pas trop comment parler de new sans introduire
un malloc() à un moment ou un autre.
Ce que je voulais dire, c'est que pour ces profs-là, une chaîne de
caractères s'écrit :
char* p= new char [taille];
i.e. une copie exacte de code C, mais en remplaçant "malloc()" par
"new".
Alors qu'on devrait enseigner d'abord std::string, et laisser les
histoires de char* pour les derniers chapitres.À l'extrème limite, un cours de C++ devrait être un cours de
programmation objet indépendant de tout langage
S'il y a des gens qui ont tendance à faire du C en C++, il y a aussi
des gens qui ont tendance à faire du Java en C++. En gros, ils
viennent de Java, et gardent leurs habitudes.
Il me semble que ce que tu proposes en fait partie. La programmation
objet est le coeur de Java. En C++, ce n'est qu'un paradigme parmi
d'autres. On l'utilise quand on en a besoin, et on utilise autre chose
quand on n'en n'a pas besoin.
Tu remarqueras qu'en C++, par défaut, les fonctions membres ne sont
pas virtuelles. Ce n'est pas une erreur.
C'est un peu pareil dans tous les langages. J'ai cherché récemment
un bouquin de référence sur les nouveautés de Fortran 2003 (même pas
2008) et j'ai eu un peu peur. Je n'en ai trouvé qu'un seul...
L'absence de bouquins de référence est moins grave : généralement, on
trouve tout ce qu'on veut sur le web, ou dans la doc du compilateur.
Ce qui est plus gênant, en revanche, c'est l'absence de bouquins pour
débutants. C'est là le moment le plus critique : enseigner au débutant
les fonctionnalités de base du langage. Si 99 % des bouquins disent
qu'une chaîne de caractères s'écrit "char*", ben on est dans la merde.
Bon courage pour trouver des candidats compétents quand tu as un poste
de programmeur C++ à pourvoir.
D'un autre côté, j'ai effectivement vu le même problème en
Javascript : J'ai trouvé un seul bouquin qui explique effectivement le
langage, "Javascript: The Good Parts" de Crockford. Et encore, il est
un peu aride pour un débutant.
On Wed, 14 Dec 2011 06:51:48 +0000 (UTC), JKB
<jkb@koenigsberg.invalid>:
Ils sont persuadés que c'est du C dans lequel
"malloc" s'écrit "new".
En fait, je ne vois pas trop comment parler de new sans introduire
un malloc() à un moment ou un autre.
Ce que je voulais dire, c'est que pour ces profs-là, une chaîne de
caractères s'écrit :
char* p= new char [taille];
i.e. une copie exacte de code C, mais en remplaçant "malloc()" par
"new".
Alors qu'on devrait enseigner d'abord std::string, et laisser les
histoires de char* pour les derniers chapitres.
À l'extrème limite, un cours de C++ devrait être un cours de
programmation objet indépendant de tout langage
S'il y a des gens qui ont tendance à faire du C en C++, il y a aussi
des gens qui ont tendance à faire du Java en C++. En gros, ils
viennent de Java, et gardent leurs habitudes.
Il me semble que ce que tu proposes en fait partie. La programmation
objet est le coeur de Java. En C++, ce n'est qu'un paradigme parmi
d'autres. On l'utilise quand on en a besoin, et on utilise autre chose
quand on n'en n'a pas besoin.
Tu remarqueras qu'en C++, par défaut, les fonctions membres ne sont
pas virtuelles. Ce n'est pas une erreur.
C'est un peu pareil dans tous les langages. J'ai cherché récemment
un bouquin de référence sur les nouveautés de Fortran 2003 (même pas
2008) et j'ai eu un peu peur. Je n'en ai trouvé qu'un seul...
L'absence de bouquins de référence est moins grave : généralement, on
trouve tout ce qu'on veut sur le web, ou dans la doc du compilateur.
Ce qui est plus gênant, en revanche, c'est l'absence de bouquins pour
débutants. C'est là le moment le plus critique : enseigner au débutant
les fonctionnalités de base du langage. Si 99 % des bouquins disent
qu'une chaîne de caractères s'écrit "char*", ben on est dans la merde.
Bon courage pour trouver des candidats compétents quand tu as un poste
de programmeur C++ à pourvoir.
D'un autre côté, j'ai effectivement vu le même problème en
Javascript : J'ai trouvé un seul bouquin qui explique effectivement le
langage, "Javascript: The Good Parts" de Crockford. Et encore, il est
un peu aride pour un débutant.
On Wed, 14 Dec 2011 06:51:48 +0000 (UTC), JKB
:Ils sont persuadés que c'est du C dans lequel
"malloc" s'écrit "new".
En fait, je ne vois pas trop comment parler de new sans introduire
un malloc() à un moment ou un autre.
Ce que je voulais dire, c'est que pour ces profs-là, une chaîne de
caractères s'écrit :
char* p= new char [taille];
i.e. une copie exacte de code C, mais en remplaçant "malloc()" par
"new".
Alors qu'on devrait enseigner d'abord std::string, et laisser les
histoires de char* pour les derniers chapitres.À l'extrème limite, un cours de C++ devrait être un cours de
programmation objet indépendant de tout langage
S'il y a des gens qui ont tendance à faire du C en C++, il y a aussi
des gens qui ont tendance à faire du Java en C++. En gros, ils
viennent de Java, et gardent leurs habitudes.
Il me semble que ce que tu proposes en fait partie. La programmation
objet est le coeur de Java. En C++, ce n'est qu'un paradigme parmi
d'autres. On l'utilise quand on en a besoin, et on utilise autre chose
quand on n'en n'a pas besoin.
Tu remarqueras qu'en C++, par défaut, les fonctions membres ne sont
pas virtuelles. Ce n'est pas une erreur.
C'est un peu pareil dans tous les langages. J'ai cherché récemment
un bouquin de référence sur les nouveautés de Fortran 2003 (même pas
2008) et j'ai eu un peu peur. Je n'en ai trouvé qu'un seul...
L'absence de bouquins de référence est moins grave : généralement, on
trouve tout ce qu'on veut sur le web, ou dans la doc du compilateur.
Ce qui est plus gênant, en revanche, c'est l'absence de bouquins pour
débutants. C'est là le moment le plus critique : enseigner au débutant
les fonctionnalités de base du langage. Si 99 % des bouquins disent
qu'une chaîne de caractères s'écrit "char*", ben on est dans la merde.
Bon courage pour trouver des candidats compétents quand tu as un poste
de programmeur C++ à pourvoir.
D'un autre côté, j'ai effectivement vu le même problème en
Javascript : J'ai trouvé un seul bouquin qui explique effectivement le
langage, "Javascript: The Good Parts" de Crockford. Et encore, il est
un peu aride pour un débutant.
begin{ma vie}
Pour avoir cherché des bons développeurs, c'est dur dans _tous_ les
langages actuellement.
begin{ma vie}
Pour avoir cherché des bons développeurs, c'est dur dans _tous_ les
langages actuellement.
begin{ma vie}
Pour avoir cherché des bons développeurs, c'est dur dans _tous_ les
langages actuellement.
Ai-je prétendu le contraire ? Mon discours est beaucoup plus simple.
en C++, on peut faire du procédural (strict) ou de l'objet.
Ai-je prétendu le contraire ? Mon discours est beaucoup plus simple.
en C++, on peut faire du procédural (strict) ou de l'objet.
Ai-je prétendu le contraire ? Mon discours est beaucoup plus simple.
en C++, on peut faire du procédural (strict) ou de l'objet.
begin{ma vie}
Pour avoir cherché des bons développeurs, c'est dur dans _tous_ les
langages actuellement. Et c'est sans compter les donneurs d'ordre qui
essayent aussi par moment de faire rentrer des idées carrées dans
des concepts ronds et qui hurlent au loup en entendant le nom de
certains langages... Au final, tu te retrouves avec des développeurs
moyens sur des langages à la mode et un code bon à jeter rapidement.
J'ai un exemple assez pathétique sur un bout de code en électronique
embarqué écrit en Java...
end{ma vie}
begin{ma vie}
Pour avoir cherché des bons développeurs, c'est dur dans _tous_ les
langages actuellement. Et c'est sans compter les donneurs d'ordre qui
essayent aussi par moment de faire rentrer des idées carrées dans
des concepts ronds et qui hurlent au loup en entendant le nom de
certains langages... Au final, tu te retrouves avec des développeurs
moyens sur des langages à la mode et un code bon à jeter rapidement.
J'ai un exemple assez pathétique sur un bout de code en électronique
embarqué écrit en Java...
end{ma vie}
begin{ma vie}
Pour avoir cherché des bons développeurs, c'est dur dans _tous_ les
langages actuellement. Et c'est sans compter les donneurs d'ordre qui
essayent aussi par moment de faire rentrer des idées carrées dans
des concepts ronds et qui hurlent au loup en entendant le nom de
certains langages... Au final, tu te retrouves avec des développeurs
moyens sur des langages à la mode et un code bon à jeter rapidement.
J'ai un exemple assez pathétique sur un bout de code en électronique
embarqué écrit en Java...
end{ma vie}
J'en suis arrivé à la conclusion qu'il n'y a que 10% de "bons
programmeurs" et encore, c'est peut-être optimiste.
J'en suis arrivé à la conclusion qu'il n'y a que 10% de "bons
programmeurs" et encore, c'est peut-être optimiste.
J'en suis arrivé à la conclusion qu'il n'y a que 10% de "bons
programmeurs" et encore, c'est peut-être optimiste.
On Wed, 14 Dec 2011 11:21:59 +0000 (UTC), JKB
:Ai-je prétendu le contraire ? Mon discours est beaucoup plus simple.
en C++, on peut faire du procédural (strict) ou de l'objet.
Ou du fonctionnel. Ou du "pseudo-objet", i.e. des classes sans
polymorphisme dynamique.
Je ne vois pas bien en quoi ça peut aider de faire un cours théorique
sur un seul des paradigmes en question.
On Wed, 14 Dec 2011 11:21:59 +0000 (UTC), JKB
<jkb@koenigsberg.invalid>:
Ai-je prétendu le contraire ? Mon discours est beaucoup plus simple.
en C++, on peut faire du procédural (strict) ou de l'objet.
Ou du fonctionnel. Ou du "pseudo-objet", i.e. des classes sans
polymorphisme dynamique.
Je ne vois pas bien en quoi ça peut aider de faire un cours théorique
sur un seul des paradigmes en question.
On Wed, 14 Dec 2011 11:21:59 +0000 (UTC), JKB
:Ai-je prétendu le contraire ? Mon discours est beaucoup plus simple.
en C++, on peut faire du procédural (strict) ou de l'objet.
Ou du fonctionnel. Ou du "pseudo-objet", i.e. des classes sans
polymorphisme dynamique.
Je ne vois pas bien en quoi ça peut aider de faire un cours théorique
sur un seul des paradigmes en question.
On Wed, 14 Dec 2011 14:24:00 +0100, Wykaaa :J'en suis arrivé à la conclusion qu'il n'y a que 10% de "bons
programmeurs" et encore, c'est peut-être optimiste.
Ça a même un nom : http://en.wikipedia.org/wiki/Sturgeon%27s_Law
On Wed, 14 Dec 2011 14:24:00 +0100, Wykaaa <wykaaa@yahoo.fr>:
J'en suis arrivé à la conclusion qu'il n'y a que 10% de "bons
programmeurs" et encore, c'est peut-être optimiste.
Ça a même un nom : http://en.wikipedia.org/wiki/Sturgeon%27s_Law
On Wed, 14 Dec 2011 14:24:00 +0100, Wykaaa :J'en suis arrivé à la conclusion qu'il n'y a que 10% de "bons
programmeurs" et encore, c'est peut-être optimiste.
Ça a même un nom : http://en.wikipedia.org/wiki/Sturgeon%27s_Law