Comme le dit le sujet, j'=E9cris ce post pour parler et d=E9battre autour d=
e l'apprentissage et l'enseignement _moderne_ du C++.
En effet, comme vous le savez sans doute, dans la majorit=E9 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 =E0 =
appr=E9hender, ce qui rend son enseignement tr=E8s d=E9licat. Les cours dis=
pens=E9s dans les diff=E9rentes =E9coles se doivent d'=EAtre rigoureux, en =
r=E9duisant 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 =E0 se tenir au gout du jour (l'informatique =E9tant un =
secteur =E9voluant tr=E8s vite), et =E0 imposer une r=E9elle rigueur dans l=
es cours dispens=E9s aux =E9l=E8ves. Au final, on se retrouve donc avec un =
cours plut=F4t approximatif, aux exemples mal choisis et idioms et pratique=
s courantes pas toujours respect=E9es.
C'est pour cela que je souhaite instaurer le d=E9bat, avec des personnes d'=
exp=E9rience, venant de l'industrie m=EAme, et ayant dans la plupart des ca=
s vu =E9voluer le langage, voire son enseignement (dans les diff=E9rents bo=
uquins, cours, ...). En outre, avec l'arriv=E9e r=E9cente 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=E9matur=E9 d'introduire certai=
nes notions et fonctionnalit=E9s de C++11 dans les cours actuels ? Pensez-v=
ous que cela rentre dans le cadre de la =AB renaissance =BB du C++, et doit=
donc faire parti de l'enseignement moderne du C++ ? A l'heure actuelle, ra=
res sont les bouquins ayant =E9t=E9 mis =E0 jour pour C++11 (=E0 part les b=
ouquins faisant =E9tat de TR1). Cela ne risque donc t-il pas de poser un pr=
obl=E8me au niveau des ressources disponibles pour les =E9tudiants ?
D'autre part, certains cours de C++ se basent et supposent, de la part des =
=E9tudiants, qu'ils poss=E8dent d=E9j=E0 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=E9ellement un sens ? Scott Meyers nous disait que l'u=
tilisation de C++ rassemblait 4 entit=E9s :
- le C
- L'orient=E9 objet
- La programmation g=E9n=E9rique avec les templates
- la STL
Est-il donc encore, en 2011, r=E9ellement productif et justifi=E9 de passer=
par la case =AB C =BB avant d'introduire le C++ ?=20
Enfin, si aujourd'hui, on vous demandait d'enseigner le C++, quelles seraie=
nt les lignes directrices de votre cours ? Quel serait le =AB plan =BB de v=
otre cours ? Passeriez-vous du temps pour =AB v=E9rifier =BB les acquis du =
C, ou bien vous concentreriez-vous exclusivement sur le C++, ses pratiques =
et ses idioms en =E9voquant les parties h=E9rit=E9es du C lorsqu'il le faut=
?
Si je pose ces questions, c'est car j'aimerais r=E9colter l'avis de personn=
es ayant pass=E9 de nombreuses ann=E9es dans l'industrie, et non pas seulem=
ent dans le domaine accad=E9mique. Les deux ne sont, selon moi, pas incompa=
tible, et peuvent travailler ensemble.
Pour moi, il y a 4 personnes très importantes sur l'objet, ce sont : Grady Booch, Bertrand Meyer (auteur du langage Eiffel), Stanley B. Lippman (pour la pédagogie sur C++ dans les années 90) et James O. Coplien. Stroustrup ne vient qu'après.
Et Koenig ?
Merci Marc. Je l'avais totalement oublié et c'est impardonnable. D'ailleurs sur l'objet, je le mets juste derrière Grady Booch et Bertrand Meyer.
Sinon tu sembles d'accord avec ma liste puisque tu n'as pas fait d'autres remarques.
Oh, dans l'optique C++, et pionniers, oui pas mal. Si on parle d'objet en general, faudrait quand meme rajouter les createurs de Smalltalk, Alan Kay en tete...
Cote vulgarisation moderne, j'ai un faible pour les ouvrages de Martin Fowler. Son bouquin sur le refactoring est franchement plutot correct.
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que ca me paraissait beaucoup trop touffu et technique.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete. Si on doit se prendre la tete, je prefere largement du Knuth... ;-)
In article <4eedd885$0$2500$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Espie a écrit :
In article <4eed400c$0$5693$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Pour moi, il y a 4 personnes très importantes sur l'objet, ce sont :
Grady Booch, Bertrand Meyer (auteur du langage Eiffel), Stanley B.
Lippman (pour la pédagogie sur C++ dans les années 90) et James O.
Coplien. Stroustrup ne vient qu'après.
Et Koenig ?
Merci Marc. Je l'avais totalement oublié et c'est impardonnable.
D'ailleurs sur l'objet, je le mets juste derrière Grady Booch et
Bertrand Meyer.
Sinon tu sembles d'accord avec ma liste puisque tu n'as pas fait
d'autres remarques.
Oh, dans l'optique C++, et pionniers, oui pas mal. Si on parle d'objet
en general, faudrait quand meme rajouter les createurs de Smalltalk,
Alan Kay en tete...
Cote vulgarisation moderne, j'ai un faible pour les ouvrages de Martin
Fowler. Son bouquin sur le refactoring est franchement plutot correct.
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup
beaucoup tendance a se perdre dans des details... j'avais teste le C++
il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que
ca me paraissait beaucoup trop touffu et technique.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres
aride, et ca manque de purete. Si on doit se prendre la tete, je prefere
largement du Knuth... ;-)
Pour moi, il y a 4 personnes très importantes sur l'objet, ce sont : Grady Booch, Bertrand Meyer (auteur du langage Eiffel), Stanley B. Lippman (pour la pédagogie sur C++ dans les années 90) et James O. Coplien. Stroustrup ne vient qu'après.
Et Koenig ?
Merci Marc. Je l'avais totalement oublié et c'est impardonnable. D'ailleurs sur l'objet, je le mets juste derrière Grady Booch et Bertrand Meyer.
Sinon tu sembles d'accord avec ma liste puisque tu n'as pas fait d'autres remarques.
Oh, dans l'optique C++, et pionniers, oui pas mal. Si on parle d'objet en general, faudrait quand meme rajouter les createurs de Smalltalk, Alan Kay en tete...
Cote vulgarisation moderne, j'ai un faible pour les ouvrages de Martin Fowler. Son bouquin sur le refactoring est franchement plutot correct.
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que ca me paraissait beaucoup trop touffu et technique.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete. Si on doit se prendre la tete, je prefere largement du Knuth... ;-)
Wykaaa
Marc Espie a écrit :
In article <4eedd885$0$2500$, Wykaaa wrote:
Marc Espie a écrit :
In article <4eed400c$0$5693$, Wykaaa wrote:
Pour moi, il y a 4 personnes très importantes sur l'objet, ce sont : Grady Booch, Bertrand Meyer (auteur du langage Eiffel), Stanley B. Lippman (pour la pédagogie sur C++ dans les années 90) et James O. Coplien. Stroustrup ne vient qu'après.
Et Koenig ?
Merci Marc. Je l'avais totalement oublié et c'est impardonnable. D'ailleurs sur l'objet, je le mets juste derrière Grady Booch et Bertrand Meyer.
Sinon tu sembles d'accord avec ma liste puisque tu n'as pas fait d'autres remarques.
Oh, dans l'optique C++, et pionniers, oui pas mal. Si on parle d'objet en general, faudrait quand meme rajouter les createurs de Smalltalk, Alan Kay en tete...
Là c'est sûr. Entièrement d'accord.
Cote vulgarisation moderne, j'ai un faible pour les ouvrages de Martin Fowler. Son bouquin sur le refactoring est franchement plutot correct.
D'accord aussi. D'autant plus que c'est un sujet qui n'est pas si souvent abordé.
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas assez de recul. Je ne crois pas que les créateurs de langages soient les mieux placés pour en parler. Le K&R n'est pas, de loin, le meilleur bouquin sur C car si les exemples montrent les possibilités du langage C, d'un point de vue strictement qualité logicielle, c'est loin du top...
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete. Si on doit se prendre la tete, je prefere largement du Knuth... ;-)
Knuth, l'indépassable, en ce qui me concerne...
Marc Espie a écrit :
In article <4eedd885$0$2500$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Espie a écrit :
In article <4eed400c$0$5693$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Pour moi, il y a 4 personnes très importantes sur l'objet, ce sont :
Grady Booch, Bertrand Meyer (auteur du langage Eiffel), Stanley B.
Lippman (pour la pédagogie sur C++ dans les années 90) et James O.
Coplien. Stroustrup ne vient qu'après.
Et Koenig ?
Merci Marc. Je l'avais totalement oublié et c'est impardonnable.
D'ailleurs sur l'objet, je le mets juste derrière Grady Booch et
Bertrand Meyer.
Sinon tu sembles d'accord avec ma liste puisque tu n'as pas fait
d'autres remarques.
Oh, dans l'optique C++, et pionniers, oui pas mal. Si on parle d'objet
en general, faudrait quand meme rajouter les createurs de Smalltalk,
Alan Kay en tete...
Là c'est sûr. Entièrement d'accord.
Cote vulgarisation moderne, j'ai un faible pour les ouvrages de Martin
Fowler. Son bouquin sur le refactoring est franchement plutot correct.
D'accord aussi. D'autant plus que c'est un sujet qui n'est pas si
souvent abordé.
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup
beaucoup tendance a se perdre dans des details... j'avais teste le C++
il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que
ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas assez de
recul. Je ne crois pas que les créateurs de langages soient les mieux
placés pour en parler. Le K&R n'est pas, de loin, le meilleur bouquin
sur C car si les exemples montrent les possibilités du langage C, d'un
point de vue strictement qualité logicielle, c'est loin du top...
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres
aride, et ca manque de purete. Si on doit se prendre la tete, je prefere
largement du Knuth... ;-)
Pour moi, il y a 4 personnes très importantes sur l'objet, ce sont : Grady Booch, Bertrand Meyer (auteur du langage Eiffel), Stanley B. Lippman (pour la pédagogie sur C++ dans les années 90) et James O. Coplien. Stroustrup ne vient qu'après.
Et Koenig ?
Merci Marc. Je l'avais totalement oublié et c'est impardonnable. D'ailleurs sur l'objet, je le mets juste derrière Grady Booch et Bertrand Meyer.
Sinon tu sembles d'accord avec ma liste puisque tu n'as pas fait d'autres remarques.
Oh, dans l'optique C++, et pionniers, oui pas mal. Si on parle d'objet en general, faudrait quand meme rajouter les createurs de Smalltalk, Alan Kay en tete...
Là c'est sûr. Entièrement d'accord.
Cote vulgarisation moderne, j'ai un faible pour les ouvrages de Martin Fowler. Son bouquin sur le refactoring est franchement plutot correct.
D'accord aussi. D'autant plus que c'est un sujet qui n'est pas si souvent abordé.
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas assez de recul. Je ne crois pas que les créateurs de langages soient les mieux placés pour en parler. Le K&R n'est pas, de loin, le meilleur bouquin sur C car si les exemples montrent les possibilités du langage C, d'un point de vue strictement qualité logicielle, c'est loin du top...
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete. Si on doit se prendre la tete, je prefere largement du Knuth... ;-)
Knuth, l'indépassable, en ce qui me concerne...
ptyxs
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beauc oup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu qu e ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas ass ez de recul. Je ne crois pas que les créateurs de langages soient les mieux placés pour en parler.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete.
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes y eux un ouvrage très pédagogique et séduisant (issu de plusieurs années d'enseignement à des débutants à l'université), qui a le grand mé rite d'enraciner des principes méthodologiques essentiels, trop souvent omis dans l'enseignement en France, dans des exemples tout à fait concrets e t détaillés, ce qui me semble exactement ce que l'on doit faire... La 'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caracté rise ce livre, c'est au contraire le va-et-vient incessant et fructueux entre principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le précédent 'Le langage C++' qui pour le coup, était quelque peu arid e et touffu et peu pédagogique. Mais PPP (rédigé avec un collège péd agogue décédé entre temps) ce n'est pas du tout, du tout cela...
Je ne veux rien supposer de désobligeant, mais c'est un gros livre et pour l'évaluer il faut plonger dedans et pas seulement le parcourir...
Une chose intéressante aussi par parenthèses : PPP est un des rares exemples d'ouvrages publiés qui montre qu'on peut (et à mon sens qu'o n doit) commencer l'enseignement du C++ par ... du C++ et non par du C (le C est abordé dans les tout derniers chapitres). Beaucoup gagneraient en France à s'en inspirer aussi à cet égard...
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beauc oup
beaucoup tendance a se perdre dans des details... j'avais teste le C++
il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu qu e
ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas ass ez de
recul. Je ne crois pas que les créateurs de langages soient les mieux
placés pour en parler.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride,
tres
aride, et ca manque de purete.
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes y eux un
ouvrage très pédagogique et séduisant (issu de plusieurs années
d'enseignement à des débutants à l'université), qui a le grand mé rite
d'enraciner des principes méthodologiques essentiels, trop souvent omis
dans l'enseignement en France, dans des exemples tout à fait concrets e t
détaillés, ce qui me semble exactement ce que l'on doit faire... La
'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caracté rise
ce livre, c'est au contraire le va-et-vient incessant et fructueux entre
principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le
précédent 'Le langage C++' qui pour le coup, était quelque peu arid e et
touffu et peu pédagogique. Mais PPP (rédigé avec un collège péd agogue
décédé entre temps) ce n'est pas du tout, du tout cela...
Je ne veux rien supposer de désobligeant, mais c'est un gros livre et
pour l'évaluer il faut plonger dedans et pas seulement le parcourir...
Une chose intéressante aussi par parenthèses : PPP est un des rares
exemples d'ouvrages publiés qui montre qu'on peut (et à mon sens qu'o n
doit) commencer l'enseignement du C++ par ... du C++ et non par du C (le
C est abordé dans les tout derniers chapitres). Beaucoup gagneraient en
France à s'en inspirer aussi à cet égard...
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beauc oup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu qu e ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas ass ez de recul. Je ne crois pas que les créateurs de langages soient les mieux placés pour en parler.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete.
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes y eux un ouvrage très pédagogique et séduisant (issu de plusieurs années d'enseignement à des débutants à l'université), qui a le grand mé rite d'enraciner des principes méthodologiques essentiels, trop souvent omis dans l'enseignement en France, dans des exemples tout à fait concrets e t détaillés, ce qui me semble exactement ce que l'on doit faire... La 'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caracté rise ce livre, c'est au contraire le va-et-vient incessant et fructueux entre principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le précédent 'Le langage C++' qui pour le coup, était quelque peu arid e et touffu et peu pédagogique. Mais PPP (rédigé avec un collège péd agogue décédé entre temps) ce n'est pas du tout, du tout cela...
Je ne veux rien supposer de désobligeant, mais c'est un gros livre et pour l'évaluer il faut plonger dedans et pas seulement le parcourir...
Une chose intéressante aussi par parenthèses : PPP est un des rares exemples d'ouvrages publiés qui montre qu'on peut (et à mon sens qu'o n doit) commencer l'enseignement du C++ par ... du C++ et non par du C (le C est abordé dans les tout derniers chapitres). Beaucoup gagneraient en France à s'en inspirer aussi à cet égard...
Fabien LE LEZ
On Mon, 19 Dec 2011 17:46:17 +0100, ptyxs :
Une chose intéressante aussi par parenthèses : PPP est un des rares exemples d'ouvrages publiés qui montre qu'on peut (et à mon sens qu'on doit) commencer l'enseignement du C++ par ... du C++ et non par du C
En fait, c'est forcément un des deux meilleurs livres de C++ pour les débutants, vu qu'il n'y en a que deux (celui-là et Accelerated C++).
On Mon, 19 Dec 2011 17:46:17 +0100, ptyxs <kerloch@gmail.com>:
Une chose intéressante aussi par parenthèses : PPP est un des rares
exemples d'ouvrages publiés qui montre qu'on peut (et à mon sens qu'on
doit) commencer l'enseignement du C++ par ... du C++ et non par du C
En fait, c'est forcément un des deux meilleurs livres de C++ pour les
débutants, vu qu'il n'y en a que deux (celui-là et Accelerated C++).
Une chose intéressante aussi par parenthèses : PPP est un des rares exemples d'ouvrages publiés qui montre qu'on peut (et à mon sens qu'on doit) commencer l'enseignement du C++ par ... du C++ et non par du C
En fait, c'est forcément un des deux meilleurs livres de C++ pour les débutants, vu qu'il n'y en a que deux (celui-là et Accelerated C++).
espie
In article <jcag8e$1icf$, Marc Espie wrote:
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...
pas encore fini de lire le brouillon de la nouvelle norme (faudra que je vois si Wiley a upgrade son edition papier, d'ailleurs).
J'en retire que ca va BEAUCOUP changer la facon d'enseigner le C++...
- il y a plein de concepts C qui vont disparaitre completement. Deja std::array<type, size> plus les initialiseurs generalises, c'est une tuerie.
- on va pouvoir expliquer les histoires de reference plus tard. Les histoires de move constructor et move assignment, tordues a expliquer, font qu'a priori, la bibliotheque standard va etre beaucoup plus efficace (tout ce qui est dequeue ne va plus du tout du tout faire de copie).
- faudra a peu pres totalement oublier les boucles a la C, au moins au debut. C'est le grand vrai retour de la programmation fonctionnelle, entre les range for et les lambda.
- cote pointeur, la-aussi ca va etre fun, entre shared_ptr<> et unique_ptr<>, on peut a peu pres oublier tout ce qui est pointeur "de base" avant tres tres tard...
je dis pas qu'il faudra pas expliquer beaucoup de choses pour aller vraiment loin, mais d'un coup, on va pouvoir quasiment directement utiliser la bibliotheque standard "pour de vrai" des le debut (hop, plus besoin d'iterateur, hop, plus besoin de const iterator, hop, les && font que les temporaires d'un coup sont beaucoup moins chiant, hop, plus besoin d'expliquer les foncteurs a la bind_two pour pouvoir utiliser les algo de base). P'tet une chance de reduire la reputation de C++ comme langage chiant, incomprehensible, et inutilisable sans s'etre mange 50 heures de cours ?...
Allez, il y a a peu pres autant de rapport entre C++98 et C++2011 qu'entre Java et Scala...
In article <jcag8e$1icf$2@saria.nerim.net>, Marc Espie <espie@nerim.net> wrote:
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...
pas encore fini de lire le brouillon de la nouvelle norme (faudra que je
vois si Wiley a upgrade son edition papier, d'ailleurs).
J'en retire que ca va BEAUCOUP changer la facon d'enseigner le C++...
- il y a plein de concepts C qui vont disparaitre completement. Deja
std::array<type, size> plus les initialiseurs generalises, c'est une tuerie.
- on va pouvoir expliquer les histoires de reference plus tard. Les
histoires de move constructor et move assignment, tordues a expliquer, font
qu'a priori, la bibliotheque standard va etre beaucoup plus efficace (tout
ce qui est dequeue ne va plus du tout du tout faire de copie).
- faudra a peu pres totalement oublier les boucles a la C, au moins au debut.
C'est le grand vrai retour de la programmation fonctionnelle, entre les
range for et les lambda.
- cote pointeur, la-aussi ca va etre fun, entre shared_ptr<> et unique_ptr<>,
on peut a peu pres oublier tout ce qui est pointeur "de base" avant tres
tres tard...
je dis pas qu'il faudra pas expliquer beaucoup de choses pour aller vraiment
loin, mais d'un coup, on va pouvoir quasiment directement utiliser la
bibliotheque standard "pour de vrai" des le debut (hop, plus besoin
d'iterateur, hop, plus besoin de const iterator, hop, les && font que les
temporaires d'un coup sont beaucoup moins chiant, hop, plus besoin d'expliquer
les foncteurs a la bind_two pour pouvoir utiliser les algo de base).
P'tet une chance de reduire la reputation de C++ comme langage chiant,
incomprehensible, et inutilisable sans s'etre mange 50 heures de cours ?...
Allez, il y a a peu pres autant de rapport entre C++98 et C++2011 qu'entre
Java et Scala...
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...
pas encore fini de lire le brouillon de la nouvelle norme (faudra que je vois si Wiley a upgrade son edition papier, d'ailleurs).
J'en retire que ca va BEAUCOUP changer la facon d'enseigner le C++...
- il y a plein de concepts C qui vont disparaitre completement. Deja std::array<type, size> plus les initialiseurs generalises, c'est une tuerie.
- on va pouvoir expliquer les histoires de reference plus tard. Les histoires de move constructor et move assignment, tordues a expliquer, font qu'a priori, la bibliotheque standard va etre beaucoup plus efficace (tout ce qui est dequeue ne va plus du tout du tout faire de copie).
- faudra a peu pres totalement oublier les boucles a la C, au moins au debut. C'est le grand vrai retour de la programmation fonctionnelle, entre les range for et les lambda.
- cote pointeur, la-aussi ca va etre fun, entre shared_ptr<> et unique_ptr<>, on peut a peu pres oublier tout ce qui est pointeur "de base" avant tres tres tard...
je dis pas qu'il faudra pas expliquer beaucoup de choses pour aller vraiment loin, mais d'un coup, on va pouvoir quasiment directement utiliser la bibliotheque standard "pour de vrai" des le debut (hop, plus besoin d'iterateur, hop, plus besoin de const iterator, hop, les && font que les temporaires d'un coup sont beaucoup moins chiant, hop, plus besoin d'expliquer les foncteurs a la bind_two pour pouvoir utiliser les algo de base). P'tet une chance de reduire la reputation de C++ comme langage chiant, incomprehensible, et inutilisable sans s'etre mange 50 heures de cours ?...
Allez, il y a a peu pres autant de rapport entre C++98 et C++2011 qu'entre Java et Scala...
espie
In article , ptyxs wrote:
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas assez de recul. Je ne crois pas que les créateurs de langages soient les mieux placés pour en parler.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete.
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes yeux un ouvrage très pédagogique et séduisant (issu de plusieurs années d'enseignement à des débutants à l'université), qui a le grand mérite d'enraciner des principes méthodologiques essentiels, trop souvent omis dans l'enseignement en France, dans des exemples tout à fait concrets et détaillés, ce qui me semble exactement ce que l'on doit faire... La 'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caractérise ce livre, c'est au contraire le va-et-vient incessant et fructueux entre principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le précédent 'Le langage C++' qui pour le coup, était quelque peu aride et touffu et peu pédagogique. Mais PPP (rédigé avec un collège pédagogue décédé entre temps) ce n'est pas du tout, du tout cela...
Non, non, j'ai bien vu le nouveau bouquin du Stroustrup. Meme s'il y a des progres par rapport au precedent, il reste "la patte" du Stroustrup: c'est souvent tres touffu sur des details techniques assez vite qui peuvent noyer le debutant ou le decourager.
Par exemple, je suis pas sur qu'attaquer sur un projet de recursive descent parser, ca soit la meilleure facon d'aborder un langage de programmation (je suis meme a peu pres sur que c'est l'une des pires, vu qu'on va melanger les difficultes de theorie des langages avec l'apprentissage du langage).
In article <4EEF6A59.6090609@gmail.com>, ptyxs <ptyxs@free.fr> wrote:
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup
beaucoup tendance a se perdre dans des details... j'avais teste le C++
il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que
ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas assez de
recul. Je ne crois pas que les créateurs de langages soient les mieux
placés pour en parler.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride,
tres
aride, et ca manque de purete.
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes yeux un
ouvrage très pédagogique et séduisant (issu de plusieurs années
d'enseignement à des débutants à l'université), qui a le grand mérite
d'enraciner des principes méthodologiques essentiels, trop souvent omis
dans l'enseignement en France, dans des exemples tout à fait concrets et
détaillés, ce qui me semble exactement ce que l'on doit faire... La
'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caractérise
ce livre, c'est au contraire le va-et-vient incessant et fructueux entre
principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le
précédent 'Le langage C++' qui pour le coup, était quelque peu aride et
touffu et peu pédagogique. Mais PPP (rédigé avec un collège pédagogue
décédé entre temps) ce n'est pas du tout, du tout cela...
Non, non, j'ai bien vu le nouveau bouquin du Stroustrup. Meme s'il y a
des progres par rapport au precedent, il reste "la patte" du Stroustrup:
c'est souvent tres touffu sur des details techniques assez vite qui peuvent
noyer le debutant ou le decourager.
Par exemple, je suis pas sur qu'attaquer sur un projet de recursive
descent parser, ca soit la meilleure facon d'aborder un langage
de programmation (je suis meme a peu pres sur que c'est l'une des pires,
vu qu'on va melanger les difficultes de theorie des langages avec
l'apprentissage du langage).
Apres, si on doit taper un peu sur Stroustrup, je trouve qu'il a beaucoup beaucoup tendance a se perdre dans des details... j'avais teste le C++ il y a longtemps, a l'epoque de l'ARM, et j'avais laisse tomber, vu que ca me paraissait beaucoup trop touffu et technique.
Voilà. C'est ce que je pense. Il n'est pas pédagogue et n'a pas assez de recul. Je ne crois pas que les créateurs de langages soient les mieux placés pour en parler.
Son bouquin d'apprentissage est un peu du meme tonneau... C'est aride, tres aride, et ca manque de purete.
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes yeux un ouvrage très pédagogique et séduisant (issu de plusieurs années d'enseignement à des débutants à l'université), qui a le grand mérite d'enraciner des principes méthodologiques essentiels, trop souvent omis dans l'enseignement en France, dans des exemples tout à fait concrets et détaillés, ce qui me semble exactement ce que l'on doit faire... La 'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caractérise ce livre, c'est au contraire le va-et-vient incessant et fructueux entre principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le précédent 'Le langage C++' qui pour le coup, était quelque peu aride et touffu et peu pédagogique. Mais PPP (rédigé avec un collège pédagogue décédé entre temps) ce n'est pas du tout, du tout cela...
Non, non, j'ai bien vu le nouveau bouquin du Stroustrup. Meme s'il y a des progres par rapport au precedent, il reste "la patte" du Stroustrup: c'est souvent tres touffu sur des details techniques assez vite qui peuvent noyer le debutant ou le decourager.
Par exemple, je suis pas sur qu'attaquer sur un projet de recursive descent parser, ca soit la meilleure facon d'aborder un langage de programmation (je suis meme a peu pres sur que c'est l'une des pires, vu qu'on va melanger les difficultes de theorie des langages avec l'apprentissage du langage).
Wykaaa
Marc Espie a écrit :
In article , ptyxs wrote:
[couic]
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes yeux un ouvrage très pédagogique et séduisant (issu de plusieurs années d'enseignement à des débutants à l'université), qui a le grand mérite d'enraciner des principes méthodologiques essentiels, trop souvent omis dans l'enseignement en France, dans des exemples tout à fait concrets et détaillés, ce qui me semble exactement ce que l'on doit faire... La 'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caractérise ce livre, c'est au contraire le va-et-vient incessant et fructueux entre principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le précédent 'Le langage C++' qui pour le coup, était quelque peu aride et touffu et peu pédagogique. Mais PPP (rédigé avec un collège pédagogue décédé entre temps) ce n'est pas du tout, du tout cela...
Non, non, j'ai bien vu le nouveau bouquin du Stroustrup. Meme s'il y a des progres par rapport au precedent, il reste "la patte" du Stroustrup: c'est souvent tres touffu sur des details techniques assez vite qui peuvent noyer le debutant ou le decourager.
Par exemple, je suis pas sur qu'attaquer sur un projet de recursive descent parser, ca soit la meilleure facon d'aborder un langage de programmation (je suis meme a peu pres sur que c'est l'une des pires, vu qu'on va melanger les difficultes de theorie des langages avec l'apprentissage du langage).
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais passé pour un grand pédagogue. D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre le C car les exemples montrent, en gros, tout ce qu'il ne faut pas écrire pour produire du logiciel de qualité.
Marc Espie a écrit :
In article <4EEF6A59.6090609@gmail.com>, ptyxs <ptyxs@free.fr> wrote:
[couic]
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes yeux un
ouvrage très pédagogique et séduisant (issu de plusieurs années
d'enseignement à des débutants à l'université), qui a le grand mérite
d'enraciner des principes méthodologiques essentiels, trop souvent omis
dans l'enseignement en France, dans des exemples tout à fait concrets et
détaillés, ce qui me semble exactement ce que l'on doit faire... La
'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caractérise
ce livre, c'est au contraire le va-et-vient incessant et fructueux entre
principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le
précédent 'Le langage C++' qui pour le coup, était quelque peu aride et
touffu et peu pédagogique. Mais PPP (rédigé avec un collège pédagogue
décédé entre temps) ce n'est pas du tout, du tout cela...
Non, non, j'ai bien vu le nouveau bouquin du Stroustrup. Meme s'il y a
des progres par rapport au precedent, il reste "la patte" du Stroustrup:
c'est souvent tres touffu sur des details techniques assez vite qui peuvent
noyer le debutant ou le decourager.
Par exemple, je suis pas sur qu'attaquer sur un projet de recursive
descent parser, ca soit la meilleure facon d'aborder un langage
de programmation (je suis meme a peu pres sur que c'est l'une des pires,
vu qu'on va melanger les difficultes de theorie des langages avec
l'apprentissage du langage).
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais
passé pour un grand pédagogue.
D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même
tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre
le C car les exemples montrent, en gros, tout ce qu'il ne faut pas
écrire pour produire du logiciel de qualité.
Aride ? PPP ? Alors là je suis sidéré, c'est au contraire à mes yeux un ouvrage très pédagogique et séduisant (issu de plusieurs années d'enseignement à des débutants à l'université), qui a le grand mérite d'enraciner des principes méthodologiques essentiels, trop souvent omis dans l'enseignement en France, dans des exemples tout à fait concrets et détaillés, ce qui me semble exactement ce que l'on doit faire... La 'pureté' n'est sûrement pas l'objectif à mon avis ! Ce qui caractérise ce livre, c'est au contraire le va-et-vient incessant et fructueux entre principes généraux et programmation la plus concrète.
Par moments, je me demande si vous ne confondez pas ce livre avec le précédent 'Le langage C++' qui pour le coup, était quelque peu aride et touffu et peu pédagogique. Mais PPP (rédigé avec un collège pédagogue décédé entre temps) ce n'est pas du tout, du tout cela...
Non, non, j'ai bien vu le nouveau bouquin du Stroustrup. Meme s'il y a des progres par rapport au precedent, il reste "la patte" du Stroustrup: c'est souvent tres touffu sur des details techniques assez vite qui peuvent noyer le debutant ou le decourager.
Par exemple, je suis pas sur qu'attaquer sur un projet de recursive descent parser, ca soit la meilleure facon d'aborder un langage de programmation (je suis meme a peu pres sur que c'est l'une des pires, vu qu'on va melanger les difficultes de theorie des langages avec l'apprentissage du langage).
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais passé pour un grand pédagogue. D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre le C car les exemples montrent, en gros, tout ce qu'il ne faut pas écrire pour produire du logiciel de qualité.
espie
In article <4f26a160$0$2528$, Wykaaa wrote:
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais passé pour un grand pédagogue. D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre le C car les exemples montrent, en gros, tout ce qu'il ne faut pas écrire pour produire du logiciel de qualité.
Un jour, j'essaierai de trouver du temps pour rassembler ce que je raconte a mes etudiants et en faire au moins un bout de bouquin...
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types opaques, par exemple, ca fait partie des trucs que je mets explicitement dans mes cours des qu'on a vu les structures... Ca fait partie des trucs "de base" en programmation C pour moi (comme l'utilisation des tableaux plus realloc pour faire des "growable array" a la std::vector... le genre de truc qui est bien plus souvent utilise en pratique que les listes chainees, en fait...)
In article <4f26a160$0$2528$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais
passé pour un grand pédagogue.
D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même
tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre
le C car les exemples montrent, en gros, tout ce qu'il ne faut pas
écrire pour produire du logiciel de qualité.
Un jour, j'essaierai de trouver du temps pour rassembler ce que je raconte
a mes etudiants et en faire au moins un bout de bouquin...
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types
opaques, par exemple, ca fait partie des trucs que je mets explicitement
dans mes cours des qu'on a vu les structures... Ca fait partie des trucs
"de base" en programmation C pour moi (comme l'utilisation des tableaux
plus realloc pour faire des "growable array" a la std::vector... le genre
de truc qui est bien plus souvent utilise en pratique que les listes
chainees, en fait...)
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais passé pour un grand pédagogue. D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre le C car les exemples montrent, en gros, tout ce qu'il ne faut pas écrire pour produire du logiciel de qualité.
Un jour, j'essaierai de trouver du temps pour rassembler ce que je raconte a mes etudiants et en faire au moins un bout de bouquin...
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types opaques, par exemple, ca fait partie des trucs que je mets explicitement dans mes cours des qu'on a vu les structures... Ca fait partie des trucs "de base" en programmation C pour moi (comme l'utilisation des tableaux plus realloc pour faire des "growable array" a la std::vector... le genre de truc qui est bien plus souvent utilise en pratique que les listes chainees, en fait...)
Wykaaa
Marc Espie a écrit :
In article <4f26a160$0$2528$, Wykaaa wrote:
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais passé pour un grand pédagogue. D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre le C car les exemples montrent, en gros, tout ce qu'il ne faut pas écrire pour produire du logiciel de qualité.
Un jour, j'essaierai de trouver du temps pour rassembler ce que je raconte a mes etudiants et en faire au moins un bout de bouquin...
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types opaques, par exemple, ca fait partie des trucs que je mets explicitement dans mes cours des qu'on a vu les structures... Ca fait partie des trucs "de base" en programmation C pour moi (comme l'utilisation des tableaux plus realloc pour faire des "growable array" a la std::vector... le genre de truc qui est bien plus souvent utilise en pratique que les listes chainees, en fait...)
Moi, j'utilisais les "virtual memory files" sur les DPS7 (Bull). Ce que je faisais ressemblait à ça : http://developers.sun.com/solaris/articles/virtual_memory_arrays.html mais adapté au système hôte.
Marc Espie a écrit :
In article <4f26a160$0$2528$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais
passé pour un grand pédagogue.
D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même
tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre
le C car les exemples montrent, en gros, tout ce qu'il ne faut pas
écrire pour produire du logiciel de qualité.
Un jour, j'essaierai de trouver du temps pour rassembler ce que je raconte
a mes etudiants et en faire au moins un bout de bouquin...
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types
opaques, par exemple, ca fait partie des trucs que je mets explicitement
dans mes cours des qu'on a vu les structures... Ca fait partie des trucs
"de base" en programmation C pour moi (comme l'utilisation des tableaux
plus realloc pour faire des "growable array" a la std::vector... le genre
de truc qui est bien plus souvent utilise en pratique que les listes
chainees, en fait...)
Moi, j'utilisais les "virtual memory files" sur les DPS7 (Bull). Ce que
je faisais ressemblait à ça :
http://developers.sun.com/solaris/articles/virtual_memory_arrays.html
mais adapté au système hôte.
Je suis entièrement d'accord avec toi Marc, Stroustrup n'est jamais passé pour un grand pédagogue. D'ailleurs, au niveau pédagogie, le K&R pour le langage C, c'est du même tonneau. Ce n'est pas le premier bouquin qu'il faut lire pour apprendre le C car les exemples montrent, en gros, tout ce qu'il ne faut pas écrire pour produire du logiciel de qualité.
Un jour, j'essaierai de trouver du temps pour rassembler ce que je raconte a mes etudiants et en faire au moins un bout de bouquin...
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types opaques, par exemple, ca fait partie des trucs que je mets explicitement dans mes cours des qu'on a vu les structures... Ca fait partie des trucs "de base" en programmation C pour moi (comme l'utilisation des tableaux plus realloc pour faire des "growable array" a la std::vector... le genre de truc qui est bien plus souvent utilise en pratique que les listes chainees, en fait...)
Moi, j'utilisais les "virtual memory files" sur les DPS7 (Bull). Ce que je faisais ressemblait à ça : http://developers.sun.com/solaris/articles/virtual_memory_arrays.html mais adapté au système hôte.
espie
In article <4f27123f$0$12491$, Wykaaa wrote:
Marc Espie a écrit :
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types opaques, par exemple, ca fait partie des trucs que je mets explicitement dans mes cours des qu'on a vu les structures... Ca fait partie des trucs "de base" en programmation C pour moi (comme l'utilisation des tableaux plus realloc pour faire des "growable array" a la std::vector... le genre de truc qui est bien plus souvent utilise en pratique que les listes chainees, en fait...)
Moi, j'utilisais les "virtual memory files" sur les DPS7 (Bull). Ce que je faisais ressemblait à ça : http://developers.sun.com/solaris/articles/virtual_memory_arrays.html mais adapté au système hôte.
J'ai lu un peu en diagonale, mais c'est pas ce genre de truc qui conduit a de l'overcommit ?..
Pour ce qui est des growable array classiques, j'ai deja retroffite ce genre de trucmuche sur le m4 BSD, avec toute la joie qu'on peut imaginer, vu qu'il y a des pointeurs a deplacer... c'est pas super-simple, mais ca marche, et c'etait plus court que tout reecrire...
Apres, pour moi, un des interets pedagogiques des growable arrays, c'est qu'on peut en profiter pour parler de bande passante memoire et de notion de localite d'acces (sans compter les optimisations habituelles des proc. pour les acces sequentiels), toutes ces petites choses que nos chers etudiants n'ont generalement pas vu, surtout quand ils ont passe 3 ans a faire de l'algo "classique" et s'imaginent que le O(1) des listes chainees ne coute pas si cher que ca par rapport a des tableaux classiques...
In article <4f27123f$0$12491$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Espie a écrit :
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types
opaques, par exemple, ca fait partie des trucs que je mets explicitement
dans mes cours des qu'on a vu les structures... Ca fait partie des trucs
"de base" en programmation C pour moi (comme l'utilisation des tableaux
plus realloc pour faire des "growable array" a la std::vector... le genre
de truc qui est bien plus souvent utilise en pratique que les listes
chainees, en fait...)
Moi, j'utilisais les "virtual memory files" sur les DPS7 (Bull). Ce que
je faisais ressemblait à ça :
http://developers.sun.com/solaris/articles/virtual_memory_arrays.html
mais adapté au système hôte.
J'ai lu un peu en diagonale, mais c'est pas ce genre de truc qui conduit
a de l'overcommit ?..
Pour ce qui est des growable array classiques, j'ai deja retroffite ce genre
de trucmuche sur le m4 BSD, avec toute la joie qu'on peut imaginer, vu qu'il
y a des pointeurs a deplacer... c'est pas super-simple, mais ca marche, et
c'etait plus court que tout reecrire...
Apres, pour moi, un des interets pedagogiques des growable arrays, c'est qu'on
peut en profiter pour parler de bande passante memoire et de notion de
localite d'acces (sans compter les optimisations habituelles des proc. pour
les acces sequentiels), toutes ces petites choses que nos chers etudiants
n'ont generalement pas vu, surtout quand ils ont passe 3 ans a faire de
l'algo "classique" et s'imaginent que le O(1) des listes chainees ne coute
pas si cher que ca par rapport a des tableaux classiques...
Les trucs comme ce qu'on a raconte dans fr.comp.lang.c sur les types opaques, par exemple, ca fait partie des trucs que je mets explicitement dans mes cours des qu'on a vu les structures... Ca fait partie des trucs "de base" en programmation C pour moi (comme l'utilisation des tableaux plus realloc pour faire des "growable array" a la std::vector... le genre de truc qui est bien plus souvent utilise en pratique que les listes chainees, en fait...)
Moi, j'utilisais les "virtual memory files" sur les DPS7 (Bull). Ce que je faisais ressemblait à ça : http://developers.sun.com/solaris/articles/virtual_memory_arrays.html mais adapté au système hôte.
J'ai lu un peu en diagonale, mais c'est pas ce genre de truc qui conduit a de l'overcommit ?..
Pour ce qui est des growable array classiques, j'ai deja retroffite ce genre de trucmuche sur le m4 BSD, avec toute la joie qu'on peut imaginer, vu qu'il y a des pointeurs a deplacer... c'est pas super-simple, mais ca marche, et c'etait plus court que tout reecrire...
Apres, pour moi, un des interets pedagogiques des growable arrays, c'est qu'on peut en profiter pour parler de bande passante memoire et de notion de localite d'acces (sans compter les optimisations habituelles des proc. pour les acces sequentiels), toutes ces petites choses que nos chers etudiants n'ont generalement pas vu, surtout quand ils ont passe 3 ans a faire de l'algo "classique" et s'imaginent que le O(1) des listes chainees ne coute pas si cher que ca par rapport a des tableaux classiques...
