Forums Développement Développement Langage C++

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 débattre 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 à =
appréhender, ce qui rend son enseignement très délicat. Les cours dis=
pensés dans les différentes écoles se doivent d'être rigoureux, en =
réduisant 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 très vite), et à imposer une réelle rigueur dans l=
es cours dispensés aux élèves. Au final, on se retrouve donc avec un =
cours plutôt approximatif, aux exemples mal choisis et idioms et pratique=
s courantes pas toujours respectées.

C'est pour cela que je souhaite instaurer le débat, avec des personnes d'=
expérience, venant de l'industrie même, et ayant dans la plupart des ca=
s vu évoluer le langage, voire son enseignement (dans les différents bo=
uquins, cours, ). En outre, avec l'arrivée récente 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 prématuré d'introduire certai=
nes notions et fonctionnalités 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=
oblème 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 possèdent déjà 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 réellement un sens ? Scott Meyers nous disait que l'u=
tilisation de C++ rassemblait 4 entités :
- le C
- L'orienté objet
- La programmation générique avec les templates
- la STL

Est-il donc encore, en 2011, réellement 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 « vérifier » les acquis du =
C, ou bien vous concentreriez-vous exclusivement sur le C++, ses pratiques =
et ses idioms en évoquant les parties héritées du C lorsqu'il le faut=
?


Si je pose ces questions, c'est car j'aimerais récolter l'avis de personn=
es ayant passé de nombreuses années dans l'industrie, et non pas seulem=
ent dans le domaine accadémique. 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]
Répondre en citant
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.
Répondre en citant
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 ;-)
Répondre en citant
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
Répondre en citant
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.
Répondre en citant
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.
Répondre en citant
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.
Répondre en citant
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
Répondre en citant
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
Répondre en citant
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 :-)
Répondre en citant
Poster une réponse
Anonyme