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.
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.
C'est toi qui envisageait de ne pas parler de langages :
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...
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...
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
Je crois qu'il préférerait gagner une participation à FreeVMS !
--
LL
Lucas Levrel
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
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
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 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
... on fait au plus simple, puis on optimise là où le profiler te dit
d'optimiser.
Espie):
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.