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 15:13:17 +0000 (UTC), Marc Boyer :
Tableaux
vector ou [] ?
vector.
J'avoue que je ne sais pas trop où mettre la syntaxe []. Si tes élèves connaissent déjà le C, tu peux te contenter d'une brève allusion en passant.
Fabien LE LEZ
On Wed, 22 Feb 2006 15:36:46 +0100, Laurent Deniau :
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
Pourquoi ?
Avec string, l'aspect template est de toutes façons caché. Il est bien rare que je m'en préoccupe.
Pour vector, il suffit de dire à tes élèves que "vector<Truc>" désigne un tableau de "Truc", tout comme "int" désigne un entier.
Pas besoin de faire une digression sur les particularités du Koenig-lookup pour les classes templates, ni même d'employer le mot "template".
On Wed, 22 Feb 2006 15:36:46 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
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
Pourquoi ?
Avec string, l'aspect template est de toutes façons caché. Il est bien
rare que je m'en préoccupe.
Pour vector, il suffit de dire à tes élèves que "vector<Truc>" désigne
un tableau de "Truc", tout comme "int" désigne un entier.
Pas besoin de faire une digression sur les particularités du
Koenig-lookup pour les classes templates, ni même d'employer le mot
"template".
On Wed, 22 Feb 2006 15:36:46 +0100, Laurent Deniau :
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
Pourquoi ?
Avec string, l'aspect template est de toutes façons caché. Il est bien rare que je m'en préoccupe.
Pour vector, il suffit de dire à tes élèves que "vector<Truc>" désigne un tableau de "Truc", tout comme "int" désigne un entier.
Pas besoin de faire une digression sur les particularités du Koenig-lookup pour les classes templates, ni même d'employer le mot "template".
Laurent Deniau
Fabien LE LEZ wrote:
On Wed, 22 Feb 2006 15:36:46 +0100, Laurent Deniau :
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
Pourquoi ?
Parce qu'un simple typedef vector<int> int_vec + une utilisation de [] sans explication est tres proche de int v[]. Le seul point eventuellement positif d'utiliser tout de suite vector, c'est la verification de l'index, mais lorsque l'exception apparaitra, il te faudra au moins 15min d'explication du pourquoi du comment de ce que voit l'etudiant a ce stade du cours.
a+, ld.
Fabien LE LEZ wrote:
On Wed, 22 Feb 2006 15:36:46 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
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
Pourquoi ?
Parce qu'un simple typedef vector<int> int_vec + une utilisation de []
sans explication est tres proche de int v[]. Le seul point
eventuellement positif d'utiliser tout de suite vector, c'est la
verification de l'index, mais lorsque l'exception apparaitra, il te
faudra au moins 15min d'explication du pourquoi du comment de ce que
voit l'etudiant a ce stade du cours.
On Wed, 22 Feb 2006 15:36:46 +0100, Laurent Deniau :
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
Pourquoi ?
Parce qu'un simple typedef vector<int> int_vec + une utilisation de [] sans explication est tres proche de int v[]. Le seul point eventuellement positif d'utiliser tout de suite vector, c'est la verification de l'index, mais lorsque l'exception apparaitra, il te faudra au moins 15min d'explication du pourquoi du comment de ce que voit l'etudiant a ce stade du cours.
a+, ld.
Fabien LE LEZ
On Wed, 22 Feb 2006 17:19:13 +0100, Laurent Deniau :
Parce qu'un simple typedef vector<int> int_vec + une utilisation de [] sans explication est tres proche de int v[].
Tu peux rajouter push_back assez vite. Ça permet de faire facilement un programme du style "demander à l'utilisateur d'entrer des nombres, un par ligne, et d'arrêter avec une ligne vide".
On Wed, 22 Feb 2006 17:19:13 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
Parce qu'un simple typedef vector<int> int_vec + une utilisation de []
sans explication est tres proche de int v[].
Tu peux rajouter push_back assez vite.
Ça permet de faire facilement un programme du style "demander à
l'utilisateur d'entrer des nombres, un par ligne, et d'arrêter avec
une ligne vide".
On Wed, 22 Feb 2006 17:19:13 +0100, Laurent Deniau :
Parce qu'un simple typedef vector<int> int_vec + une utilisation de [] sans explication est tres proche de int v[].
Tu peux rajouter push_back assez vite. Ça permet de faire facilement un programme du style "demander à l'utilisateur d'entrer des nombres, un par ligne, et d'arrêter avec une ligne vide".
Marc Boyer
Le 22-02-2006, Fabien LE LEZ a écrit :
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.
J'avais noté ;-)
Il y a un certain nombre de fonctionnalités plutôt simples, et reprises dans pas mal de langages.
Oui, mais à quoi penses tu ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 22-02-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
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.
J'avais noté ;-)
Il y a un certain nombre de fonctionnalités plutôt simples, et
reprises dans pas mal de langages.
Oui, mais à quoi penses tu ?
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling
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.
J'avais noté ;-)
Il y a un certain nombre de fonctionnalités plutôt simples, et reprises dans pas mal de langages.
Oui, mais à quoi penses tu ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Marc Boyer
Le 22-02-2006, Yoxoman a écrit :
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++.
Oui, c'est une de mes inspiration, même si j'ai l'impression qu'ils s'arrêtent au II (mais je viens de le préter, je parle de mémoire...)
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.
En puis j'ai l'impression que beaucoup de monde voit le C++ comme une grosse machinerie avec une théorie objet complexe. Est-ce qu'on peut gagner à faire du C++ sans être super fort en théorie objet ? J'essaye de voir comment enseigner le C++ ainsi.
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.
Je l'ai lu il y a trop longtemps. Faudra que je revois en effet.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 22-02-2006, Yoxoman <yhpnfyrqber@tznvy.pbz> a écrit :
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++.
Oui, c'est une de mes inspiration, même si j'ai l'impression
qu'ils s'arrêtent au II (mais je viens de le préter, je parle
de mémoire...)
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.
En puis j'ai l'impression que beaucoup de monde voit le C++
comme une grosse machinerie avec une théorie objet complexe.
Est-ce qu'on peut gagner à faire du C++ sans être super fort
en théorie objet ? J'essaye de voir comment enseigner le C++
ainsi.
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.
Je l'ai lu il y a trop longtemps. Faudra que je revois en effet.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling
C'est un plan assez proche de la structure de Accelerated C++.
Oui, c'est une de mes inspiration, même si j'ai l'impression qu'ils s'arrêtent au II (mais je viens de le préter, je parle de mémoire...)
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.
En puis j'ai l'impression que beaucoup de monde voit le C++ comme une grosse machinerie avec une théorie objet complexe. Est-ce qu'on peut gagner à faire du C++ sans être super fort en théorie objet ? J'essaye de voir comment enseigner le C++ ainsi.
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.
Je l'ai lu il y a trop longtemps. Faudra que je revois en effet.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Marc Boyer
Le 22-02-2006, Fabien LE LEZ a écrit :
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 ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 22-02-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
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 ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling
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 ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Marc Boyer
Le 22-02-2006, Laurent Deniau a écrit :
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.
Je suis d'accord, c'était pour situer le débat ici, en faisant référence à une culture commune.
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.
Va falloir que j'apprenne l'électronique. Heuh, dans l'idéal, se serait bien. Mais je sais pas si je vais avoir le temps.
Du coup ta structure n'est plus appropriee ;-)
Je crois que je suivrais plutot qqchose du genre (a vue de nez):
Je fais un découpage.
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op) STL-use I (vector, iostream, iterator, algoI) string quand même, non ?
scope & namespace & lifetime
C'est ce que je voyais en 'strate I', ie C++ comme langage impératif procédural moderne.
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)
C'est globalement le II que j'imaginais (avec les templates en plus, mais vous avez levé certaines de mes réticences).
STL-use III (alloc) polymorphism III (covariance, contravariance, vtable) overloading III (resolution) template III (resolution) meta-programming II (intro) STL-use IV (valarray)
Il manque un mode d'emplois sur certains mécanismes. Présenter la différence methode publique/privée, c'est facile. Dire qu'on peut faire un opérateur de copie privé, c'est une phrase à dire. Mais quand l'utiliser...
Une chose qui me manque dans les cours de C++ que j'ai vu, c'est qu'on présente des mécanismes relativement indépendants, sans dire comment s'en servir.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 22-02-2006, Laurent Deniau <laurent.deniau@cern.ch> a écrit :
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.
Je suis d'accord, c'était pour situer le débat ici, en faisant
référence à une culture commune.
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.
Va falloir que j'apprenne l'électronique. Heuh, dans l'idéal,
se serait bien. Mais je sais pas si je vais avoir le temps.
Du coup ta structure n'est plus appropriee ;-)
Je crois que je suivrais plutot qqchose du genre (a vue de nez):
Je fais un découpage.
basics (type, var, func, loop, TU)
overloading I (func)
template I (func)
overloading II (op)
STL-use I (vector, iostream, iterator, algoI)
string quand même, non ?
scope & namespace & lifetime
C'est ce que je voyais en 'strate I', ie C++ comme langage
impératif procédural moderne.
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)
C'est globalement le II que j'imaginais (avec les templates
en plus, mais vous avez levé certaines de mes réticences).
STL-use III (alloc)
polymorphism III (covariance, contravariance, vtable)
overloading III (resolution)
template III (resolution)
meta-programming II (intro)
STL-use IV (valarray)
Il manque un mode d'emplois sur certains mécanismes.
Présenter la différence methode publique/privée, c'est facile.
Dire qu'on peut faire un opérateur de copie privé, c'est
une phrase à dire. Mais quand l'utiliser...
Une chose qui me manque dans les cours de C++ que j'ai vu,
c'est qu'on présente des mécanismes relativement indépendants,
sans dire comment s'en servir.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling
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.
Je suis d'accord, c'était pour situer le débat ici, en faisant référence à une culture commune.
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.
Va falloir que j'apprenne l'électronique. Heuh, dans l'idéal, se serait bien. Mais je sais pas si je vais avoir le temps.
Du coup ta structure n'est plus appropriee ;-)
Je crois que je suivrais plutot qqchose du genre (a vue de nez):
Je fais un découpage.
basics (type, var, func, loop, TU) overloading I (func) template I (func) overloading II (op) STL-use I (vector, iostream, iterator, algoI) string quand même, non ?
scope & namespace & lifetime
C'est ce que je voyais en 'strate I', ie C++ comme langage impératif procédural moderne.
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)
C'est globalement le II que j'imaginais (avec les templates en plus, mais vous avez levé certaines de mes réticences).
STL-use III (alloc) polymorphism III (covariance, contravariance, vtable) overloading III (resolution) template III (resolution) meta-programming II (intro) STL-use IV (valarray)
Il manque un mode d'emplois sur certains mécanismes. Présenter la différence methode publique/privée, c'est facile. Dire qu'on peut faire un opérateur de copie privé, c'est une phrase à dire. Mais quand l'utiliser...
Une chose qui me manque dans les cours de C++ que j'ai vu, c'est qu'on présente des mécanismes relativement indépendants, sans dire comment s'en servir.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Loïc Joly
On Wed, 22 Feb 2006 17:19:13 +0100, Laurent Deniau :
Parce qu'un simple typedef vector<int> int_vec + une utilisation de [] sans explication est tres proche de int v[].
Tu peux rajouter push_back assez vite.
Et size
-- Loïc
On Wed, 22 Feb 2006 17:19:13 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
Parce qu'un simple typedef vector<int> int_vec + une utilisation de []
sans explication est tres proche de int v[].
On Wed, 22 Feb 2006 17:19:13 +0100, Laurent Deniau :
Parce qu'un simple typedef vector<int> int_vec + une utilisation de [] sans explication est tres proche de int v[].
Tu peux rajouter push_back assez vite.
Et size
-- Loïc
kanze
Laurent Deniau wrote:
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
Seulement que ça ne marche pas. Les élèves vont vouloir afficher des résultats -- ils sont donc obligés à se servir au moins de std::cout. Et je vois les tableaux aussi comme quelque chose d'assez fondamental. Donc, std::vector.
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++.
OK. C'est même plus basic que je ne l'aurais imaginé. AMHA, il te faut quand même std::cout.
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.
Il me semble que Marc a dit qu'ils connaissent déjà le C. Ce qui change beaucoup. Par exemple, je suis d'accord avec ta rémarque de ne pas comparer aux autres langages. Mais s'ils connaissent le C, on ne pourrait pas empécher qu'ils reconnaissent les ressemblances, et qu'ils font la comparaison eux-mêmes.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Laurent Deniau wrote:
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
Seulement que ça ne marche pas. Les élèves vont vouloir afficher
des résultats -- ils sont donc obligés à se servir au moins de
std::cout. Et je vois les tableaux aussi comme quelque chose
d'assez fondamental. Donc, std::vector.
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++.
OK. C'est même plus basic que je ne l'aurais imaginé. AMHA, il
te faut quand même std::cout.
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.
Il me semble que Marc a dit qu'ils connaissent déjà le C. Ce qui
change beaucoup. Par exemple, je suis d'accord avec ta rémarque
de ne pas comparer aux autres langages. Mais s'ils connaissent
le C, on ne pourrait pas empécher qu'ils reconnaissent les
ressemblances, et qu'ils font la comparaison eux-mêmes.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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
Seulement que ça ne marche pas. Les élèves vont vouloir afficher des résultats -- ils sont donc obligés à se servir au moins de std::cout. Et je vois les tableaux aussi comme quelque chose d'assez fondamental. Donc, std::vector.
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++.
OK. C'est même plus basic que je ne l'aurais imaginé. AMHA, il te faut quand même std::cout.
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.
Il me semble que Marc a dit qu'ils connaissent déjà le C. Ce qui change beaucoup. Par exemple, je suis d'accord avec ta rémarque de ne pas comparer aux autres langages. Mais s'ils connaissent le C, on ne pourrait pas empécher qu'ils reconnaissent les ressemblances, et qu'ils font la comparaison eux-mêmes.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
