L'apprentissage et l'enseignement moderne du C++

Le
Mathieu STEFANI
Bonjour tous,

Comme le dit le sujet, j'cris ce post pour parler et dbattre autour d=
e l'apprentissage et l'enseignement _moderne_ du C++.

En effet, comme vous le savez sans doute, dans la majorit des cursus inf=
ormatiques (tout du moins, en France), l'on retrouve toute une partie sur l=
'apprentissage de la programmation, et sur le C++.
De mon point de vue, il s'agit de l'un des langages les plus complexes =
apprhender, ce qui rend son enseignement trs dlicat. Les cours dis=
penss dans les diffrentes coles se doivent d'tre rigoureux, en =
rduisant le plus possible les approximations que l'on pourrait y trouver=
.

Cependant, de ma propre constatation, au sein du corps enseignant, rares so=
nt les enseignants se tenir au gout du jour (l'informatique tant un =
secteur voluant trs vite), et imposer une relle rigueur dans l=
es cours dispenss aux lves. Au final, on se retrouve donc avec un =
cours plutt approximatif, aux exemples mal choisis et idioms et pratique=
s courantes pas toujours respectes.

C'est pour cela que je souhaite instaurer le dbat, avec des personnes d'=
exprience, venant de l'industrie mme, et ayant dans la plupart des ca=
s vu voluer le langage, voire son enseignement (dans les diffrents bo=
uquins, cours, ). En outre, avec l'arrive rcente du nouveau standa=
rd C++11, cela risque de remettre pas mal de choses et de cours en question=
.

Pensez-vous qu'il est pour l'instant trop prmatur d'introduire certai=
nes notions et fonctionnalits de C++11 dans les cours actuels ? Pensez-v=
ous que cela rentre dans le cadre de la renaissance du C++, et doit=
donc faire parti de l'enseignement moderne du C++ ? A l'heure actuelle, ra=
res sont les bouquins ayant t mis jour pour C++11 ( part les b=
ouquins faisant tat de TR1). Cela ne risque donc t-il pas de poser un pr=
oblme au niveau des ressources disponibles pour les tudiants ?

D'autre part, certains cours de C++ se basent et supposent, de la part des =
tudiants, qu'ils possdent dj des bases en C. Ainsi, ces cours r=
eposent sur des notions acquises en C. Pensez-vous qu'aujourd'hui, en 2011,=
cela a t-il encore rellement un sens ? Scott Meyers nous disait que l'u=
tilisation de C++ rassemblait 4 entits :
- le C
- L'orient objet
- La programmation gnrique avec les templates
- la STL

Est-il donc encore, en 2011, rellement productif et justifi de passer=
par la case C avant d'introduire le C++ ?

Enfin, si aujourd'hui, on vous demandait d'enseigner le C++, quelles seraie=
nt les lignes directrices de votre cours ? Quel serait le plan de v=
otre cours ? Passeriez-vous du temps pour vrifier les acquis du =
C, ou bien vous concentreriez-vous exclusivement sur le C++, ses pratiques =
et ses idioms en voquant les parties hrites du C lorsqu'il le faut=
?


Si je pose ces questions, c'est car j'aimerais rcolter l'avis de personn=
es ayant pass de nombreuses annes dans l'industrie, et non pas seulem=
ent dans le domaine accadmique. Les deux ne sont, selon moi, pas incompa=
tible, et peuvent travailler ensemble.

Cordialement.
  • Partager ce contenu :
Vos réponses Page 2 / 6
Trier par : date / pertinence
Wykaaa
Le #24067581
Mathieu STEFANI a écrit :
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).



Quand on fait des cours de 5 jours en entreprise, la STL ne peut être
traitée en détail. On se contente d'énumérer les classes les plus
importantes avec leur s fonctionnalités. Dans un cours universitaire
c'est autre chose mais c'est au détriment d'autres domaines.

Notre discussion oublie un point, pourtant essentiel, c'est la
conception objet. Je ne conçois pas qu'on puisse faire apprendre un
langage objet sans parler de conception objet.
A ce titre, le livre de Stroustrup me paraît indispensable car il lie la
COO et la POO (quelques fois maladroitement d'ailleurs).


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.



Je suis d'accord.

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++).



Mon chouchou sur le sujet est Stanley B. Lippman qui avait écrit, en son
temps déjà, le C++ primer qui, à l'époque, était le meilleur livre sur 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



Je ne connais pas mais je vais regarder...

[snip le reste]
Fabien LE LEZ
Le #24067981
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.
Wykaaa
Le #24068221
JKB a écrit :
Le Wed, 14 Dec 2011 09:20:15 +0100,
Wykaaa
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 ?



Effectivement. Je l'avais oublié celui-là. De plus, VMS est un des
meilleurs OS que j'ai connu.

Tu gagnes ma considération et c'est beaucoup ;-)
JKB
Le #24068351
Le Wed, 14 Dec 2011 11:26:05 +0100,
Fabien LE LEZ
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".



Et ceux-là, il faudrait leur botter le cul une bonne fois pour
toute.

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.



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. Et
lorsque je parle de faire un cours de programmation orientée objet,
je ne parle surtout pas de Java (ni de C++). Il faut avant tout que
le développeur de base sache ce qu'il doit utiliser et quand pour ne
pas essayer de faire rentrer une idée ronde dans un concept carré.

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.



Ouaips... Mais un bouquin de référence Fortran2003 ou 2008 va un
peu plus loin que la doc du compilateur. Il y a des subtilités dans
les C_BINDING ou les SEQUENCE que je n'ai jamais vu dans aucune doc
de compilo.

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.



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}

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.



JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Fabien LE LEZ
Le #24068841
On Wed, 14 Dec 2011 11:21:59 +0000 (UTC), JKB

begin{ma vie}
Pour avoir cherché des bons développeurs, c'est dur dans _tous_ les
langages actuellement.



J'ai lu quelque part que les bons développeurs ne sont jamais sur le
marché du travail ; il faut aller les débaucher là où ils bossent.
Fabien LE LEZ
Le #24068831
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.
Wykaaa
Le #24068821
JKB a écrit :


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}



Hélas ce n'est pas nouveau. Durant toute ma vie professionnelle j'ai été
confronté à cela.
J'en suis arrivé à la conclusion qu'il n'y a que 10% de "bons
programmeurs" et encore, c'est peut-être optimiste.

Par "bon programmeur", j'entends :
- Un programmeur qui connaît parfaitement le(s) langage(s) dans
le(s)quel(s) il programme (syntaxe ET sémantique)
- Un programmeur qui ne met pas son ego dans la programmation (du style,
regarde ce que j'ai écrit, tout ce que ça fait en 2 lignes...)
- Un programmeur qui respecte le cahier des charges, l'analyse et la
conception qui ont été faites en amont
- Un programmeur qui optimise "raisonnablement" son programme et qui ne
cherche pas à en optimiser la totalité (à l'exécution, un programme
passe 80% de son temps dans 20% du code. Ce sont ces 20% qu'il faut
optimiser)
- Un programmeur qui "ne joue pas" avec les aspects les plus obscurs du
langage

Tout ceci paraît trivial mais de tels programmeurs sont très difficiles
à trouver.
Fabien LE LEZ
Le #24068811
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
JKB
Le #24068911
Le Wed, 14 Dec 2011 14:22:54 +0100,
Fabien LE LEZ
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.



Parce que je ne vois pas comment attaquer brutalement le C++ sans
avoir quelques connaissances sur des langages plus simple. Attaquer
par el C++, c'est faisable, mais c'est tout de même ardu.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Wykaaa
Le #24068901
Fabien LE LEZ a écrit :
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



Merci. J'ai appris quelque chose aujourd'hui :-)
Poster une réponse
Anonyme