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 3 / 6
Trier par : date / pertinence
Fabien LE LEZ
Le #24069061
On Wed, 14 Dec 2011 13:32:10 +0000 (UTC), JKB

Parce que je ne vois pas comment attaquer brutalement le C++ sans
avoir quelques connaissances sur des langages plus simple.



C'est toi qui envisageait de ne pas parler de langages :
À l'extrème limite, un cours de C++ devrait être un cours de
programmation objet indépendant de tout langage
espie
Le #24069541
In article Fabien LE LEZ
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.



J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins
en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de
te farcir des char *.

Rappel: les std::string de 98 etaient un rajout un peu de derniere minute, et
par exemple, il n'y a meme pas de constructeur de fichier qui prend un
std::string en parametre... ca fait un peu pitie.

Du coup, les chausse-trappes a la .c_str prennent une importance quelque
peu disproportionnee, mais malheureusement justifiee...
espie
Le #24069531
In article JKB
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



ca va etre beaucoup moins casse-bonbons en C++2011 qu'en 98, hein. Une fois
qu'on pourra faire vraiment plus que le cours theorique, et qu'on sera
certain qu'en lachant les etudiants sur du projet, ils vont tomber sur des
trucs existants, et pas sur un bout de bibliotheque encore manquante a emuler
a la main...
Lucas Levrel
Le #24071861
Le 14 décembre 2011, Wykaaa a écrit :

Fabien LE LEZ a écrit :
Comparé au passage par valeur, le passage par référence constante
n'est qu'une optimisation, que le compilo devrait se charger de faire
lui-même.



Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca
devrait être le défaut.
Pourquoi ?
Parce que à chaque passage par valeur d'une instance de classe qui comporte
un constructeur de copie, celui-ci est appelé alors que dans la majorité des
cas ce n'est pas nécessaire.
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 !



Est-ce que le passage par référence constante est plus efficace que le
passage par valeur pour les types « élémentaires » (je ne connais pas le
terme canonique) char, int, float, double ?

--
LL
Lucas Levrel
Le #24071851
Le 14 décembre 2011, Wykaaa a écrit :

JKB a écrit :
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 ;-)



Je crois qu'il préférerait gagner une participation à FreeVMS !

--
LL
JKB
Le #24072011
Le Thu, 15 Dec 2011 10:02:27 +0100,
Lucas Levrel
Le 14 décembre 2011, Wykaaa a écrit :

Fabien LE LEZ a écrit :
Comparé au passage par valeur, le passage par référence constante
n'est qu'une optimisation, que le compilo devrait se charger de faire
lui-même.



Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca
devrait être le défaut.
Pourquoi ?
Parce que à chaque passage par valeur d'une instance de classe qui comporte
un constructeur de copie, celui-ci est appelé alors que dans la majorité des
cas ce n'est pas nécessaire.
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 !



Est-ce que le passage par référence constante est plus efficace que le
passage par valeur pour les types « élémentaires » (je ne connais pas le
terme canonique) char, int, float, double ?



J'aurais tendance à dire que ça dépend de l'architecture (et du type
et du nombre de piles utilisées, voire de la fenêtre de registres et
de problèmes rigolo d'alignement des données en mémoire...).
Typiquement, sur du sparc, la réponse est non tant qu'on ne dépasse
pas huit arguments de même type. Si on dépasse ces huit arguments,
il vaut mieux utiliser une référence constante parce qu'on sort de
la fenêtre. Sur du x86, ça va dépendre de l'ABI (en 32 bits, il y a
une foultitude d'ABI concurrentes alors qu'en 64 bits, un esprit sage
a réussi à limiter ce nombre à ... 1 !). Sous VMS, DEC C et C++
optimisent un peu dans le dos de l'utilisateur. C'est vrai sur VAX parce
que l'assembleur est vraiment bien fichu (il connaît même directement
les listes chaînées), mais je n'ai pas regardé sur mon Alpha le code
généré.

Il n'y a donc pas de réponse simple à cette question, mais dans le
doute...

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
Jean-Marc Bourguet
Le #24072261
Fabien LE LEZ
Comparé au passage par valeur, le passage par référence co nstante
n'est qu'une optimisation, que le compilo devrait se charger de faire
lui-même.



Comment? La semantique est differente.

void f(int x, int& y) {
y = 5;
std::cout << x << 'n';
}

et

void f(int const& x, int& y) {
y = 5;
std::cout << x << 'n';
}

vont afficher quelque chose de different pour

int x = 42;
f(x, x);

Et j'ai deja vu le probleme sur du "vrai" code.

Pourquoi, cette optimisation n'est pas toujours pertinente. Voir par
exemple http://cpp-next.com/archive/2009/08/want-speed-pass-by-value

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Le #24072661
Wykaaa
Ton exemple, c'est vraiment, comme on dit, prendre des bâtons pour s e faire
battre, bien que cela puisse effectivement exister dans du vrai code. Cel ui
qui se fait piéger l'aura quand même bien mérité !



C'est un moyen simple pour avoir un alias. Il y en a d'autres plus
realistes. Tu peux arguer en faveur d'une approche plus fonctionnelle
et dependant moins d'un etat, je ne te contredirai pas. Mais passer de
la a dire que le compilateur doit changer la semantique de ton
programme, je ne suis pas d'accord. On n'est pas dans un cas ou la
semantique n'est pas clairement specifiee, elle l'est. Le compilateur
ne doit l'ignorer sous pretexte d'optimisation.

Et puis je ne parlais des passages par référence constante que pour
les instances de classes, pas pour les types primitifs.



Et quelle est la difference fondamentale? Si tu transformes un passage
par valeur en un passage par reference, tu supposes que tu n'as pas
d'alias. Que ce soit pour des types simples ou des classes.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
Le #24073421
On Thu, 15 Dec 2011 09:35:12 +0000 (UTC), JKB

mais dans le
doute...



... on fait au plus simple, puis on optimise là où le profiler te dit
d'optimiser.
Fabien LE LEZ
Le #24073571
On Wed, 14 Dec 2011 15:41:48 +0000 (UTC), (Marc
Espie):

J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins
en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de
te farcir des char *.

[...]
par exemple, il n'y a meme pas de constructeur de fichier qui prend un
std::string en parametre... ca fait un peu pitie.

Du coup, les chausse-trappes a la .c_str [...]



Au moins au début du cours, on peut considérer .c_str() comme une
incantation magique.
Par ailleurs, il s'agit de "char const*", ce qui est tout de même plus
facile à gérer, puisque std::string s'occupe de l'allocation
dynamique, de la vérification des bornes, etc.
Poster une réponse
Anonyme