risquant d'avoir à faire un cours de C++, je réflechissais
un peu à la présentation générale, à la hiérarchisation des
connaissances en C++.
Je vois actuellement 3 strates dans C++:
I. "C++ as a better C"
C++ comme un langage impératif procédural, sans objet
utilisateur (ie presque que des POD), une sorte de C
augmenté par les E/S iostream, iofstream, les conteneurs
STL (vector, list..), string, les itérateurs et les algos
(find, remove...)
Et puis surtout les références et const.
Eventuellement la surcharge des opérateurs.
II. C++ comme un Java-like
Introduction des objets, methodes, encapsulation
(public/private).
Vie de l'objet: constructeur/destructeur, opérateur
de copie, constructeur de copie, tous public.
Héritage public / polymorphisme dynamique: virtual...
III. C++ comme support à la conception
Tout ce qui permet à C++ de gérer des patterns
particuliers: les opérateurs de vie de l'objet privé,
l'héritage privé.
Et puis il y a aussi l'écriture de ses propres classes
templates, qui me semble possible sérieusement qu'après
avoir intégré le II, que je mets donc là même si c'est
peut-être orthogonal.
Cette réflexion me semble importante car C++ est
souvent rejetté de par sa complexité. Et c'est vrai
qu'il me semble que beaucoup de l'agitation autour de
C++ se fait dans le III, que c'est peut-être la partie
intellectuellement la plus exitante, mais qu'elle ne
peut qu'effrayer la majorité des débutants.
Voilà, dans mon cours, je viserais plutôt I et II.
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
risquant d'avoir à faire un cours de C++ [...]
I. "C++ as a better C"
Ou "as a better PHP" ?..
C++ comme un langage impératif procédural, sans objet utilisateur (ie presque que des POD) [...] Introduction des objets, methodes, encapsulation (public/private).
Gnourf ? Tu voudrais mettre les objets POD dans le I, et une introduction aux objets dans le II ? Ça me paraît un peu artificiel.
Je trouve ton découpage un peu trop "absolu". En particulier, je mettrais certainement une introduction aux objets _avant_ l'étude des bizarreries de std::remove, histoire d'aller en ordre croissant de difficulté.
Vie de l'objet: constructeur/destructeur, opérateur de copie, constructeur de copie, tous public.
J'imagine que tu mets là-dedans l'introduction à new/delete, les pointeurs intelligents et les GC ?
Et puis il y a aussi l'écriture de ses propres classes templates, qui me semble possible sérieusement qu'après avoir intégré le II
Bof. Créer une classe template (ou une fonction template) toute simple, c'est loin d'être la mer à boire.
En fait, je verrais bien un plan assez différent : introduire les fonctionnalités assez tôt, puis aller de plus en plus loin dans les subtilités.
Exemple :
Notion de variable std::cout (histoire de savoir afficher des résultats dès le début) Chaînes de caractères Tableaux Fonctions Classes (d'abord des classes ne contenant que des objets, puis on passe aux fonctions membres) Fonctions/classes templates (les bases) Iterateurs
Une fois qu'on a ces notions basiques, on peut passer à l'héritage simple, puis aux fonctions virtuelles, aux subtilités des templates, à std::remove() qui n'enlève rien, au Koenig-lookup, etc.
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
risquant d'avoir à faire un cours de C++ [...]
I. "C++ as a better C"
Ou "as a better PHP" ?..
C++ comme un langage impératif procédural, sans objet
utilisateur
(ie presque que des POD)
[...]
Introduction des objets, methodes, encapsulation
(public/private).
Gnourf ?
Tu voudrais mettre les objets POD dans le I, et une introduction aux
objets dans le II ?
Ça me paraît un peu artificiel.
Je trouve ton découpage un peu trop "absolu". En particulier, je
mettrais certainement une introduction aux objets _avant_ l'étude des
bizarreries de std::remove, histoire d'aller en ordre croissant de
difficulté.
Vie de l'objet: constructeur/destructeur, opérateur
de copie, constructeur de copie, tous public.
J'imagine que tu mets là-dedans l'introduction à new/delete, les
pointeurs intelligents et les GC ?
Et puis il y a aussi l'écriture de ses propres classes
templates, qui me semble possible sérieusement qu'après
avoir intégré le II
Bof.
Créer une classe template (ou une fonction template) toute simple,
c'est loin d'être la mer à boire.
En fait, je verrais bien un plan assez différent : introduire les
fonctionnalités assez tôt, puis aller de plus en plus loin dans les
subtilités.
Exemple :
Notion de variable
std::cout (histoire de savoir afficher des résultats dès le début)
Chaînes de caractères
Tableaux
Fonctions
Classes (d'abord des classes ne contenant que des objets, puis on
passe aux fonctions membres)
Fonctions/classes templates (les bases)
Iterateurs
Une fois qu'on a ces notions basiques, on peut passer à l'héritage
simple, puis aux fonctions virtuelles, aux subtilités des templates, à
std::remove() qui n'enlève rien, au Koenig-lookup, etc.
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
risquant d'avoir à faire un cours de C++ [...]
I. "C++ as a better C"
Ou "as a better PHP" ?..
C++ comme un langage impératif procédural, sans objet utilisateur (ie presque que des POD) [...] Introduction des objets, methodes, encapsulation (public/private).
Gnourf ? Tu voudrais mettre les objets POD dans le I, et une introduction aux objets dans le II ? Ça me paraît un peu artificiel.
Je trouve ton découpage un peu trop "absolu". En particulier, je mettrais certainement une introduction aux objets _avant_ l'étude des bizarreries de std::remove, histoire d'aller en ordre croissant de difficulté.
Vie de l'objet: constructeur/destructeur, opérateur de copie, constructeur de copie, tous public.
J'imagine que tu mets là-dedans l'introduction à new/delete, les pointeurs intelligents et les GC ?
Et puis il y a aussi l'écriture de ses propres classes templates, qui me semble possible sérieusement qu'après avoir intégré le II
Bof. Créer une classe template (ou une fonction template) toute simple, c'est loin d'être la mer à boire.
En fait, je verrais bien un plan assez différent : introduire les fonctionnalités assez tôt, puis aller de plus en plus loin dans les subtilités.
Exemple :
Notion de variable std::cout (histoire de savoir afficher des résultats dès le début) Chaînes de caractères Tableaux Fonctions Classes (d'abord des classes ne contenant que des objets, puis on passe aux fonctions membres) Fonctions/classes templates (les bases) Iterateurs
Une fois qu'on a ces notions basiques, on peut passer à l'héritage simple, puis aux fonctions virtuelles, aux subtilités des templates, à std::remove() qui n'enlève rien, au Koenig-lookup, etc.
Fabien LE LEZ
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
Je vois actuellement 3 strates dans C++:
Histoire de clarifier mon précédent message, je ne suis pas du tout d'accord avec cette vision des choses.
Il y a un certain nombre de fonctionnalités plutôt simples, et reprises dans pas mal de langages.
Et puis, il y a des "subtilités", de plus en plus complexes au fur et à mesure qu'on a besoin de fonctionnalités particulières.
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
Je vois actuellement 3 strates dans C++:
Histoire de clarifier mon précédent message, je ne suis pas du tout
d'accord avec cette vision des choses.
Il y a un certain nombre de fonctionnalités plutôt simples, et
reprises dans pas mal de langages.
Et puis, il y a des "subtilités", de plus en plus complexes au fur et
à mesure qu'on a besoin de fonctionnalités particulières.
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
Je vois actuellement 3 strates dans C++:
Histoire de clarifier mon précédent message, je ne suis pas du tout d'accord avec cette vision des choses.
Il y a un certain nombre de fonctionnalités plutôt simples, et reprises dans pas mal de langages.
Et puis, il y a des "subtilités", de plus en plus complexes au fur et à mesure qu'on a besoin de fonctionnalités particulières.
Yoxoman
I. "C++ as a better C"
II. C++ comme un Java-like
III. C++ comme support à la conception
C'est un plan assez proche de la structure de Accelerated C++.
Contrairement à Fabien, je pense que c'est une bonne chose.
La première partie permet d'accentuer la différence entre le C et le C++ au niveau procédural. C'est un domaine apparemment mal compris des étudiants. Ils auraient tendance à voir le C++ uniquement comme un C avec une grosse théorie autour des objets. Et donc dérouler toute l'artillerie qui permet de faire du procédural de manière différente (en particulier avec la STL) ne peut être que bénéfique.
Egalement d'accord pour le reste. Bien qu'il soit articulé autour d'exemples, je pense que tu peux te baser (pour le contenu) sur l'excellent bouquin de Koenig & Moo.
-- "Yo!" Martin Heidegger
I. "C++ as a better C"
II. C++ comme un Java-like
III. C++ comme support à la conception
C'est un plan assez proche de la structure de Accelerated C++.
Contrairement à Fabien, je pense que c'est une bonne chose.
La première partie permet d'accentuer la différence entre le C et le C++
au niveau procédural. C'est un domaine apparemment mal compris des
étudiants. Ils auraient tendance à voir le C++ uniquement comme un C
avec une grosse théorie autour des objets. Et donc dérouler toute
l'artillerie qui permet de faire du procédural de manière différente (en
particulier avec la STL) ne peut être que bénéfique.
Egalement d'accord pour le reste. Bien qu'il soit articulé autour
d'exemples, je pense que tu peux te baser (pour le contenu) sur
l'excellent bouquin de Koenig & Moo.
C'est un plan assez proche de la structure de Accelerated C++.
Contrairement à Fabien, je pense que c'est une bonne chose.
La première partie permet d'accentuer la différence entre le C et le C++ au niveau procédural. C'est un domaine apparemment mal compris des étudiants. Ils auraient tendance à voir le C++ uniquement comme un C avec une grosse théorie autour des objets. Et donc dérouler toute l'artillerie qui permet de faire du procédural de manière différente (en particulier avec la STL) ne peut être que bénéfique.
Egalement d'accord pour le reste. Bien qu'il soit articulé autour d'exemples, je pense que tu peux te baser (pour le contenu) sur l'excellent bouquin de Koenig & Moo.
-- "Yo!" Martin Heidegger
Fabien LE LEZ
On Wed, 22 Feb 2006 10:52:55 +0100, Yoxoman :
La première partie permet d'accentuer la différence entre le C et le C++ au niveau procédural. C'est un domaine apparemment mal compris des étudiants. Ils auraient tendance à voir le C++ uniquement comme un C avec une grosse théorie autour des objets.
C'est donc un cours fait pour des programmeurs C ?
La transition C -> C++ est (presque) aussi difficile que la transition rien -> C++, mais considérablement différente.
On Wed, 22 Feb 2006 10:52:55 +0100, Yoxoman <yhpnfyrqber@tznvy.pbz>:
La première partie permet d'accentuer la différence entre le C et le C++
au niveau procédural. C'est un domaine apparemment mal compris des
étudiants. Ils auraient tendance à voir le C++ uniquement comme un C
avec une grosse théorie autour des objets.
C'est donc un cours fait pour des programmeurs C ?
La transition C -> C++ est (presque) aussi difficile que la transition
rien -> C++, mais considérablement différente.
La première partie permet d'accentuer la différence entre le C et le C++ au niveau procédural. C'est un domaine apparemment mal compris des étudiants. Ils auraient tendance à voir le C++ uniquement comme un C avec une grosse théorie autour des objets.
C'est donc un cours fait pour des programmeurs C ?
La transition C -> C++ est (presque) aussi difficile que la transition rien -> C++, mais considérablement différente.
Laurent Deniau
Marc Boyer wrote:
Bonjour à tous,
risquant d'avoir à faire un cours de C++, je réflechissais un peu à la présentation générale, à la hiérarchisation des connaissances en C++.
Je vois actuellement 3 strates dans C++:
D'un point de vue general, je ne parlerais pas des autres langages (C inclu) parce que ca n'apporte rien et ca ne peux que produire des confusions, ou des racourcis abusifs dans la tete de certains etudiants. Sans compter que pendant ma courte experience d'enseignement du C et du C++ j'ai pu constater que moins les eleves avaient de reperes annexes (autres experiences, autres langages) plus ils etaient attentifs et neutres face a ce que tu leur dis. Ca evitait les "je connais deja, je peux glander tranquille" ou "c'est comme Java, je maitrise". Et dans la meme lignee, je commencerais par 10min sur un exemple poilu de resolution de probleme en C++ sur un sujet de leur domaine, histoire de calmer ceux qui connaissent deja (croient connaitre) C++ et d'eveiller la curiosite des autres en abordant un sujet qui les interesse. Tu pourras aussi revenir dessus une fois les notions necessaires acquises ce qui leur montrera leur evolution.
La comparaison de C++ aux autres langages, je la ferais eventuellement dans un hypothetique IV (notament au niveau des patterns) si tu as le temps en fin de module sinon je donnerais des references sur le sujet (elles ne manquent pas!).
Du coup ta structure n'est plus appropriee ;-)
Je crois que je suivrais plutot qqchose du genre (a vue de nez):
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op) STL-use I (vector, iostream, iterator, algoI) scope & namespace & lifetime class I (0 base, encapI) ctor, dtor I inheritance I (single) class II (1 base, encapII) exception template II (class) traits meta-programming I (factorielle) STL-use II (string, map, iostream, algoII) polymorphism I (virtual) ctor, dtor II (virtual) inheritance II (multi, virtual) polymorphism II (multi, virtual) STL-use III (alloc) polymorphism III (covariance, contravariance, vtable) overloading III (resolution) template III (resolution) meta-programming II (intro) STL-use IV (valarray)
a+, ld.
Marc Boyer wrote:
Bonjour à tous,
risquant d'avoir à faire un cours de C++, je réflechissais
un peu à la présentation générale, à la hiérarchisation des
connaissances en C++.
Je vois actuellement 3 strates dans C++:
D'un point de vue general, je ne parlerais pas des autres langages (C
inclu) parce que ca n'apporte rien et ca ne peux que produire des
confusions, ou des racourcis abusifs dans la tete de certains etudiants.
Sans compter que pendant ma courte experience d'enseignement du C et du
C++ j'ai pu constater que moins les eleves avaient de reperes annexes
(autres experiences, autres langages) plus ils etaient attentifs et
neutres face a ce que tu leur dis. Ca evitait les "je connais deja, je
peux glander tranquille" ou "c'est comme Java, je maitrise". Et dans la
meme lignee, je commencerais par 10min sur un exemple poilu de
resolution de probleme en C++ sur un sujet de leur domaine, histoire de
calmer ceux qui connaissent deja (croient connaitre) C++ et d'eveiller
la curiosite des autres en abordant un sujet qui les interesse. Tu
pourras aussi revenir dessus une fois les notions necessaires acquises
ce qui leur montrera leur evolution.
La comparaison de C++ aux autres langages, je la ferais eventuellement
dans un hypothetique IV (notament au niveau des patterns) si tu as le
temps en fin de module sinon je donnerais des references sur le sujet
(elles ne manquent pas!).
Du coup ta structure n'est plus appropriee ;-)
Je crois que je suivrais plutot qqchose du genre (a vue de nez):
basics (type, var, func, loop, TU)
overloading I (func)
template I (func)
overloading II (op)
STL-use I (vector, iostream, iterator, algoI)
scope & namespace & lifetime
class I (0 base, encapI)
ctor, dtor I
inheritance I (single)
class II (1 base, encapII)
exception
template II (class)
traits
meta-programming I (factorielle)
STL-use II (string, map, iostream, algoII)
polymorphism I (virtual)
ctor, dtor II (virtual)
inheritance II (multi, virtual)
polymorphism II (multi, virtual)
STL-use III (alloc)
polymorphism III (covariance, contravariance, vtable)
overloading III (resolution)
template III (resolution)
meta-programming II (intro)
STL-use IV (valarray)
risquant d'avoir à faire un cours de C++, je réflechissais un peu à la présentation générale, à la hiérarchisation des connaissances en C++.
Je vois actuellement 3 strates dans C++:
D'un point de vue general, je ne parlerais pas des autres langages (C inclu) parce que ca n'apporte rien et ca ne peux que produire des confusions, ou des racourcis abusifs dans la tete de certains etudiants. Sans compter que pendant ma courte experience d'enseignement du C et du C++ j'ai pu constater que moins les eleves avaient de reperes annexes (autres experiences, autres langages) plus ils etaient attentifs et neutres face a ce que tu leur dis. Ca evitait les "je connais deja, je peux glander tranquille" ou "c'est comme Java, je maitrise". Et dans la meme lignee, je commencerais par 10min sur un exemple poilu de resolution de probleme en C++ sur un sujet de leur domaine, histoire de calmer ceux qui connaissent deja (croient connaitre) C++ et d'eveiller la curiosite des autres en abordant un sujet qui les interesse. Tu pourras aussi revenir dessus une fois les notions necessaires acquises ce qui leur montrera leur evolution.
La comparaison de C++ aux autres langages, je la ferais eventuellement dans un hypothetique IV (notament au niveau des patterns) si tu as le temps en fin de module sinon je donnerais des references sur le sujet (elles ne manquent pas!).
Du coup ta structure n'est plus appropriee ;-)
Je crois que je suivrais plutot qqchose du genre (a vue de nez):
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op) STL-use I (vector, iostream, iterator, algoI) scope & namespace & lifetime class I (0 base, encapI) ctor, dtor I inheritance I (single) class II (1 base, encapII) exception template II (class) traits meta-programming I (factorielle) STL-use II (string, map, iostream, algoII) polymorphism I (virtual) ctor, dtor II (virtual) inheritance II (multi, virtual) polymorphism II (multi, virtual) STL-use III (alloc) polymorphism III (covariance, contravariance, vtable) overloading III (resolution) template III (resolution) meta-programming II (intro) STL-use IV (valarray)
a+, ld.
Fabien LE LEZ
On Wed, 22 Feb 2006 12:15:03 +0100, Laurent Deniau :
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op)
STL-use I (vector, iostream, iterator, algoI) [...] STL-use II (string, map, iostream, algoII)
J'imagine que par "vector", "iostream" et "string", tu entends "étude des détails de ces machins", car tu as abordé les bases de l'utilisation de ces trois-là dans "basics" ?
On Wed, 22 Feb 2006 12:15:03 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
basics (type, var, func, loop, TU)
overloading I (func)
template I (func)
overloading II (op)
STL-use I (vector, iostream, iterator, algoI)
[...]
STL-use II (string, map, iostream, algoII)
J'imagine que par "vector", "iostream" et "string", tu entends "étude
des détails de ces machins", car tu as abordé les bases de
l'utilisation de ces trois-là dans "basics" ?
On Wed, 22 Feb 2006 12:15:03 +0100, Laurent Deniau :
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op)
STL-use I (vector, iostream, iterator, algoI) [...] STL-use II (string, map, iostream, algoII)
J'imagine que par "vector", "iostream" et "string", tu entends "étude des détails de ces machins", car tu as abordé les bases de l'utilisation de ces trois-là dans "basics" ?
Laurent Deniau
Fabien LE LEZ wrote:
On Wed, 22 Feb 2006 12:15:03 +0100, Laurent Deniau :
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op)
STL-use I (vector, iostream, iterator, algoI) [...] STL-use II (string, map, iostream, algoII)
J'imagine que par "vector", "iostream" et "string", tu entends "étude des détails de ces machins", car tu as abordé les bases de l'utilisation de ces trois-là dans "basics" ?
Non, dans basics je n'aborderais rien qui soit lie a la STL
basic porterait plutot sur [char,int,unsigned,double], un ou deux POD (sous forme de struct), main, qque var, while (pas de do-while ni de switch, et for je le garde pour plus tard, par ex avec les iterateurs), qques fonctions, const mais seulement vu comme du read-only (a-la-C), la notion d'include et de TU (avec un peu de pp). Qqchose de tres succint mais essentiel et indispensable pour commencer. Surtout pas commencer un cours magistral de C ou de C vu du C++.
J'adapterais eventuellement la pertinence de basics au niveau des eleves, par exemple s'ils ont deja vu le C ou Java a un niveau avance.
a+, ld.
Fabien LE LEZ wrote:
On Wed, 22 Feb 2006 12:15:03 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
basics (type, var, func, loop, TU)
overloading I (func)
template I (func)
overloading II (op)
STL-use I (vector, iostream, iterator, algoI)
[...]
STL-use II (string, map, iostream, algoII)
J'imagine que par "vector", "iostream" et "string", tu entends "étude
des détails de ces machins", car tu as abordé les bases de
l'utilisation de ces trois-là dans "basics" ?
Non, dans basics je n'aborderais rien qui soit lie a la STL
basic porterait plutot sur [char,int,unsigned,double], un ou deux POD
(sous forme de struct), main, qque var, while (pas de do-while ni de
switch, et for je le garde pour plus tard, par ex avec les iterateurs),
qques fonctions, const mais seulement vu comme du read-only (a-la-C), la
notion d'include et de TU (avec un peu de pp). Qqchose de tres succint
mais essentiel et indispensable pour commencer. Surtout pas commencer un
cours magistral de C ou de C vu du C++.
J'adapterais eventuellement la pertinence de basics au niveau des
eleves, par exemple s'ils ont deja vu le C ou Java a un niveau avance.
On Wed, 22 Feb 2006 12:15:03 +0100, Laurent Deniau :
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op)
STL-use I (vector, iostream, iterator, algoI) [...] STL-use II (string, map, iostream, algoII)
J'imagine que par "vector", "iostream" et "string", tu entends "étude des détails de ces machins", car tu as abordé les bases de l'utilisation de ces trois-là dans "basics" ?
Non, dans basics je n'aborderais rien qui soit lie a la STL
basic porterait plutot sur [char,int,unsigned,double], un ou deux POD (sous forme de struct), main, qque var, while (pas de do-while ni de switch, et for je le garde pour plus tard, par ex avec les iterateurs), qques fonctions, const mais seulement vu comme du read-only (a-la-C), la notion d'include et de TU (avec un peu de pp). Qqchose de tres succint mais essentiel et indispensable pour commencer. Surtout pas commencer un cours magistral de C ou de C vu du C++.
J'adapterais eventuellement la pertinence de basics au niveau des eleves, par exemple s'ils ont deja vu le C ou Java a un niveau avance.
a+, ld.
Fabien LE LEZ
On Wed, 22 Feb 2006 14:18:13 +0100, Laurent Deniau :
Non, dans basics je n'aborderais rien qui soit lie a la STL basic porterait plutot sur [char,int,unsigned,double],
Se passer totalement de tableaux et de chaînes pendant plusieurs chapitres, ça risque d'être dur à gérer, non ? Après tout, ce sont des types presque aussi fréquents que "int", et (au moins dans mon code) très largement plus fréquents que "double".
On Wed, 22 Feb 2006 14:18:13 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
Non, dans basics je n'aborderais rien qui soit lie a la STL
basic porterait plutot sur [char,int,unsigned,double],
Se passer totalement de tableaux et de chaînes pendant plusieurs
chapitres, ça risque d'être dur à gérer, non ?
Après tout, ce sont des types presque aussi fréquents que "int", et
(au moins dans mon code) très largement plus fréquents que "double".
On Wed, 22 Feb 2006 14:18:13 +0100, Laurent Deniau :
Non, dans basics je n'aborderais rien qui soit lie a la STL basic porterait plutot sur [char,int,unsigned,double],
Se passer totalement de tableaux et de chaînes pendant plusieurs chapitres, ça risque d'être dur à gérer, non ? Après tout, ce sont des types presque aussi fréquents que "int", et (au moins dans mon code) très largement plus fréquents que "double".
Laurent Deniau
Fabien LE LEZ wrote:
On Wed, 22 Feb 2006 14:18:13 +0100, Laurent Deniau :
Non, dans basics je n'aborderais rien qui soit lie a la STL basic porterait plutot sur [char,int,unsigned,double],
Se passer totalement de tableaux et de chaînes pendant plusieurs chapitres, ça risque d'être dur à gérer, non ?
Pour le prof oui, il faut bien murir ses chapitres de depart. Mais pour les eleves c'est leur offrir la possibilite d'avoir des bases moins mouvantes. C'est un peu comme en topologie, au debut on a rien (presque le neant) et je trouve les exercices tres difficiles. Ensuite les outils viennent et meme si plus de concepts sont introduit, ca devient plus facile (ou tout du moins moins abstrait).
Après tout, ce sont des types presque aussi fréquents que "int", et (au moins dans mon code) très largement plus fréquents que "double".
Si tu veux tout de meme utiliser string ou vector, tu peux preparer un include fait-mains dans lequel tu mets des typedefs ou des macros pour que les eleves ne voit pas l'aspect template, voir tu fais des wrappeurs pour les rendre immutables, ce qui simplifie une premiere approche de leur utilisation. Idem pour les references. Ensuite une fois les concepts vus (ce qui arrive rapidement dans mon plan), tu leurs montre le contenu de l'include avec qques explications et l'introduction a la SL n'en sera que plus facile.
a+, ld.
Fabien LE LEZ wrote:
On Wed, 22 Feb 2006 14:18:13 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
Non, dans basics je n'aborderais rien qui soit lie a la STL
basic porterait plutot sur [char,int,unsigned,double],
Se passer totalement de tableaux et de chaînes pendant plusieurs
chapitres, ça risque d'être dur à gérer, non ?
Pour le prof oui, il faut bien murir ses chapitres de depart. Mais pour
les eleves c'est leur offrir la possibilite d'avoir des bases moins
mouvantes. C'est un peu comme en topologie, au debut on a rien (presque
le neant) et je trouve les exercices tres difficiles. Ensuite les outils
viennent et meme si plus de concepts sont introduit, ca devient plus
facile (ou tout du moins moins abstrait).
Après tout, ce sont des types presque aussi fréquents que "int", et
(au moins dans mon code) très largement plus fréquents que "double".
Si tu veux tout de meme utiliser string ou vector, tu peux preparer un
include fait-mains dans lequel tu mets des typedefs ou des macros pour
que les eleves ne voit pas l'aspect template, voir tu fais des wrappeurs
pour les rendre immutables, ce qui simplifie une premiere approche de
leur utilisation. Idem pour les references. Ensuite une fois les
concepts vus (ce qui arrive rapidement dans mon plan), tu leurs montre
le contenu de l'include avec qques explications et l'introduction a la
SL n'en sera que plus facile.
On Wed, 22 Feb 2006 14:18:13 +0100, Laurent Deniau :
Non, dans basics je n'aborderais rien qui soit lie a la STL basic porterait plutot sur [char,int,unsigned,double],
Se passer totalement de tableaux et de chaînes pendant plusieurs chapitres, ça risque d'être dur à gérer, non ?
Pour le prof oui, il faut bien murir ses chapitres de depart. Mais pour les eleves c'est leur offrir la possibilite d'avoir des bases moins mouvantes. C'est un peu comme en topologie, au debut on a rien (presque le neant) et je trouve les exercices tres difficiles. Ensuite les outils viennent et meme si plus de concepts sont introduit, ca devient plus facile (ou tout du moins moins abstrait).
Après tout, ce sont des types presque aussi fréquents que "int", et (au moins dans mon code) très largement plus fréquents que "double".
Si tu veux tout de meme utiliser string ou vector, tu peux preparer un include fait-mains dans lequel tu mets des typedefs ou des macros pour que les eleves ne voit pas l'aspect template, voir tu fais des wrappeurs pour les rendre immutables, ce qui simplifie une premiere approche de leur utilisation. Idem pour les references. Ensuite une fois les concepts vus (ce qui arrive rapidement dans mon plan), tu leurs montre le contenu de l'include avec qques explications et l'introduction a la SL n'en sera que plus facile.
a+, ld.
Marc Boyer
Le 22-02-2006, Fabien LE LEZ a écrit :
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
risquant d'avoir à faire un cours de C++ [...]
I. "C++ as a better C"
Ou "as a better PHP" ?..
J'ai repris la phrase de BS. De plus, je suis bien trop incompétent en PHP pour donner un avis sur les liens avec C++.
C++ comme un langage impératif procédural, sans objet utilisateur (ie presque que des POD) [...] Introduction des objets, methodes, encapsulation (public/private).
Gnourf ? Tu voudrais mettre les objets POD dans le I, et une introduction aux objets dans le II ? Ça me paraît un peu artificiel.
Je suis trop absorbé dans mon monde: le public a déjà fait du C.
Je trouve ton découpage un peu trop "absolu". En particulier, je mettrais certainement une introduction aux objets _avant_ l'étude des bizarreries de std::remove, histoire d'aller en ordre croissant de difficulté.
Oui, remove était vraiment pas le bon exemple. Parlons plutot de find, copy...
Vie de l'objet: constructeur/destructeur, opérateur de copie, constructeur de copie, tous public.
J'imagine que tu mets là-dedans l'introduction à new/delete, les pointeurs intelligents et les GC ?
Voui.
Et puis il y a aussi l'écriture de ses propres classes templates, qui me semble possible sérieusement qu'après avoir intégré le II
Bof. Créer une classe template (ou une fonction template) toute simple, c'est loin d'être la mer à boire.
Pourquoi pas.
En fait, je verrais bien un plan assez différent : introduire les fonctionnalités assez tôt, puis aller de plus en plus loin dans les subtilités.
Exemple :
Notion de variable std::cout (histoire de savoir afficher des résultats dès le début) Chaînes de caractères Tableaux
vector ou [] ?
Fonctions Classes (d'abord des classes ne contenant que des objets, puis on passe aux fonctions membres) Fonctions/classes templates (les bases) Iterateurs
OK, avec la restriction des opérateurs 'de vie' public.
Une fois qu'on a ces notions basiques, on peut passer à l'héritage simple, puis aux fonctions virtuelles, aux subtilités des templates, à std::remove() qui n'enlève rien, au Koenig-lookup, etc.
C'est dans cette partie là que je trouve qu'on a le plus de mal à se positionner. Ca me semble trop touffu.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Le 22-02-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
risquant d'avoir à faire un cours de C++ [...]
I. "C++ as a better C"
Ou "as a better PHP" ?..
J'ai repris la phrase de BS. De plus, je suis bien trop
incompétent en PHP pour donner un avis sur les liens avec C++.
C++ comme un langage impératif procédural, sans objet
utilisateur
(ie presque que des POD)
[...]
Introduction des objets, methodes, encapsulation
(public/private).
Gnourf ?
Tu voudrais mettre les objets POD dans le I, et une introduction aux
objets dans le II ?
Ça me paraît un peu artificiel.
Je suis trop absorbé dans mon monde: le public a déjà
fait du C.
Je trouve ton découpage un peu trop "absolu". En particulier, je
mettrais certainement une introduction aux objets _avant_ l'étude des
bizarreries de std::remove, histoire d'aller en ordre croissant de
difficulté.
Oui, remove était vraiment pas le bon exemple. Parlons
plutot de find, copy...
Vie de l'objet: constructeur/destructeur, opérateur
de copie, constructeur de copie, tous public.
J'imagine que tu mets là-dedans l'introduction à new/delete, les
pointeurs intelligents et les GC ?
Voui.
Et puis il y a aussi l'écriture de ses propres classes
templates, qui me semble possible sérieusement qu'après
avoir intégré le II
Bof.
Créer une classe template (ou une fonction template) toute simple,
c'est loin d'être la mer à boire.
Pourquoi pas.
En fait, je verrais bien un plan assez différent : introduire les
fonctionnalités assez tôt, puis aller de plus en plus loin dans les
subtilités.
Exemple :
Notion de variable
std::cout (histoire de savoir afficher des résultats dès le début)
Chaînes de caractères
Tableaux
vector ou [] ?
Fonctions
Classes (d'abord des classes ne contenant que des objets, puis on
passe aux fonctions membres)
Fonctions/classes templates (les bases)
Iterateurs
OK, avec la restriction des opérateurs 'de vie' public.
Une fois qu'on a ces notions basiques, on peut passer à l'héritage
simple, puis aux fonctions virtuelles, aux subtilités des templates, à
std::remove() qui n'enlève rien, au Koenig-lookup, etc.
C'est dans cette partie là que je trouve qu'on a le plus de mal à
se positionner. Ca me semble trop touffu.
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain
On Wed, 22 Feb 2006 08:32:30 +0000 (UTC), Marc Boyer :
risquant d'avoir à faire un cours de C++ [...]
I. "C++ as a better C"
Ou "as a better PHP" ?..
J'ai repris la phrase de BS. De plus, je suis bien trop incompétent en PHP pour donner un avis sur les liens avec C++.
C++ comme un langage impératif procédural, sans objet utilisateur (ie presque que des POD) [...] Introduction des objets, methodes, encapsulation (public/private).
Gnourf ? Tu voudrais mettre les objets POD dans le I, et une introduction aux objets dans le II ? Ça me paraît un peu artificiel.
Je suis trop absorbé dans mon monde: le public a déjà fait du C.
Je trouve ton découpage un peu trop "absolu". En particulier, je mettrais certainement une introduction aux objets _avant_ l'étude des bizarreries de std::remove, histoire d'aller en ordre croissant de difficulté.
Oui, remove était vraiment pas le bon exemple. Parlons plutot de find, copy...
Vie de l'objet: constructeur/destructeur, opérateur de copie, constructeur de copie, tous public.
J'imagine que tu mets là-dedans l'introduction à new/delete, les pointeurs intelligents et les GC ?
Voui.
Et puis il y a aussi l'écriture de ses propres classes templates, qui me semble possible sérieusement qu'après avoir intégré le II
Bof. Créer une classe template (ou une fonction template) toute simple, c'est loin d'être la mer à boire.
Pourquoi pas.
En fait, je verrais bien un plan assez différent : introduire les fonctionnalités assez tôt, puis aller de plus en plus loin dans les subtilités.
Exemple :
Notion de variable std::cout (histoire de savoir afficher des résultats dès le début) Chaînes de caractères Tableaux
vector ou [] ?
Fonctions Classes (d'abord des classes ne contenant que des objets, puis on passe aux fonctions membres) Fonctions/classes templates (les bases) Iterateurs
OK, avec la restriction des opérateurs 'de vie' public.
Une fois qu'on a ces notions basiques, on peut passer à l'héritage simple, puis aux fonctions virtuelles, aux subtilités des templates, à std::remove() qui n'enlève rien, au Koenig-lookup, etc.
C'est dans cette partie là que je trouve qu'on a le plus de mal à se positionner. Ca me semble trop touffu.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
