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 Thu, 23 Feb 2006 10:56:44 +0100, Laurent Deniau :
techinquement les templates sont plus compliques que le polymorphisme d'heritage
Tiens ? J'aimerais bien que tu m'expliques ça. J'ai toujours trouvé que c'était le contraire.
[Note : j'ai fait beaucoup de maths avant de me mettre au C++ ; j'avais donc déjà l'habitude des constructions du genre "soit x un élément d'un ensemble E" où on ne précise pas la nature des éléments. Ceci explique peut-être cela.]
On Thu, 23 Feb 2006 10:56:44 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
techinquement les templates sont plus compliques que le polymorphisme
d'heritage
Tiens ? J'aimerais bien que tu m'expliques ça. J'ai toujours trouvé
que c'était le contraire.
[Note : j'ai fait beaucoup de maths avant de me mettre au C++ ;
j'avais donc déjà l'habitude des constructions du genre "soit x un
élément d'un ensemble E" où on ne précise pas la nature des éléments.
Ceci explique peut-être cela.]
On Thu, 23 Feb 2006 10:56:44 +0100, Laurent Deniau :
techinquement les templates sont plus compliques que le polymorphisme d'heritage
Tiens ? J'aimerais bien que tu m'expliques ça. J'ai toujours trouvé que c'était le contraire.
[Note : j'ai fait beaucoup de maths avant de me mettre au C++ ; j'avais donc déjà l'habitude des constructions du genre "soit x un élément d'un ensemble E" où on ne précise pas la nature des éléments. Ceci explique peut-être cela.]
Fabien LE LEZ
On Thu, 23 Feb 2006 13:45:06 +0000 (UTC), Marc Boyer :
J'ai réalise cette année en effet que dans la POO, on se jettais souvent directement dans les bras du polymorphisme d'héritage sans insister sur encapsullation et ctor/dtor.
Je confirme que c'est pas glop. D'autant que le polymorphisme d'héritage n'est jamais qu'un paradigme, certes utiles dans certains cas, mais pas indispensable partout et tout le temps. Alors qu'écrire un programme fiable sans encapsuler, ça risque d'être très vite de la haute voltige.
On Thu, 23 Feb 2006 13:45:06 +0000 (UTC), Marc Boyer :
J'ai réalise cette année en effet que dans la POO, on se jettais
souvent directement dans les bras du polymorphisme d'héritage sans
insister sur encapsullation et ctor/dtor.
Je confirme que c'est pas glop. D'autant que le polymorphisme
d'héritage n'est jamais qu'un paradigme, certes utiles dans certains
cas, mais pas indispensable partout et tout le temps. Alors qu'écrire
un programme fiable sans encapsuler, ça risque d'être très vite de la
haute voltige.
On Thu, 23 Feb 2006 13:45:06 +0000 (UTC), Marc Boyer :
J'ai réalise cette année en effet que dans la POO, on se jettais souvent directement dans les bras du polymorphisme d'héritage sans insister sur encapsullation et ctor/dtor.
Je confirme que c'est pas glop. D'autant que le polymorphisme d'héritage n'est jamais qu'un paradigme, certes utiles dans certains cas, mais pas indispensable partout et tout le temps. Alors qu'écrire un programme fiable sans encapsuler, ça risque d'être très vite de la haute voltige.
Marc Boyer
Le 23-02-2006, Fabien LE LEZ a écrit :
On Wed, 22 Feb 2006 19:29:20 +0000 (UTC), Marc Boyer :
C'est donc un cours fait pour des programmeurs C ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Si les élèves connaissent déjà le C, on peut passer rapidement sur les trucs de base (notion de variable, de fonction), et surtout aborder très rapidement des notions qui n'existent pas en C (string, vector, fonctions membres, etc.), histoire de leur montrer qu'on parle d'un langage fondamentalement différent, et pas d'une simple extension au C.
Un programme qui demande à l'utilisateur de saisir des mots me paraît pas mal : on balance tout de suite iostream, string et vector, et on obtient quelque chose de très différent, et beaucoup plus simple, que ce qui se ferait en C.
Tout à fait. On peut ajouter des entiers aussi pour montrer qu'on a plus de %d...
Bon, après, la gestion des erreurs dans le format d'entrée, je pense que c'est pénible dans les deux langages.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 23-02-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
On Wed, 22 Feb 2006 19:29:20 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
C'est donc un cours fait pour des programmeurs C ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Si les élèves connaissent déjà le C, on peut passer rapidement sur les
trucs de base (notion de variable, de fonction), et surtout aborder
très rapidement des notions qui n'existent pas en C (string, vector,
fonctions membres, etc.), histoire de leur montrer qu'on parle d'un
langage fondamentalement différent, et pas d'une simple extension au
C.
Un programme qui demande à l'utilisateur de saisir des mots me paraît
pas mal : on balance tout de suite iostream, string et vector, et on
obtient quelque chose de très différent, et beaucoup plus simple, que
ce qui se ferait en C.
Tout à fait. On peut ajouter des entiers aussi pour montrer
qu'on a plus de %d...
Bon, après, la gestion des erreurs dans le format d'entrée,
je pense que c'est pénible dans les deux langages.
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 19:29:20 +0000 (UTC), Marc Boyer :
C'est donc un cours fait pour des programmeurs C ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Si les élèves connaissent déjà le C, on peut passer rapidement sur les trucs de base (notion de variable, de fonction), et surtout aborder très rapidement des notions qui n'existent pas en C (string, vector, fonctions membres, etc.), histoire de leur montrer qu'on parle d'un langage fondamentalement différent, et pas d'une simple extension au C.
Un programme qui demande à l'utilisateur de saisir des mots me paraît pas mal : on balance tout de suite iostream, string et vector, et on obtient quelque chose de très différent, et beaucoup plus simple, que ce qui se ferait en C.
Tout à fait. On peut ajouter des entiers aussi pour montrer qu'on a plus de %d...
Bon, après, la gestion des erreurs dans le format d'entrée, je pense que c'est pénible dans les deux langages.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Fabien LE LEZ
On Wed, 22 Feb 2006 19:29:20 +0000 (UTC), Marc Boyer :
C'est donc un cours fait pour des programmeurs C ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Si les élèves connaissent déjà le C, on peut passer rapidement sur les trucs de base (notion de variable, de fonction), et surtout aborder très rapidement des notions qui n'existent pas en C (string, vector, fonctions membres, etc.), histoire de leur montrer qu'on parle d'un langage fondamentalement différent, et pas d'une simple extension au C.
Un programme qui demande à l'utilisateur de saisir des mots me paraît pas mal : on balance tout de suite iostream, string et vector, et on obtient quelque chose de très différent, et beaucoup plus simple, que ce qui se ferait en C.
On Wed, 22 Feb 2006 19:29:20 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
C'est donc un cours fait pour des programmeurs C ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Si les élèves connaissent déjà le C, on peut passer rapidement sur les
trucs de base (notion de variable, de fonction), et surtout aborder
très rapidement des notions qui n'existent pas en C (string, vector,
fonctions membres, etc.), histoire de leur montrer qu'on parle d'un
langage fondamentalement différent, et pas d'une simple extension au
C.
Un programme qui demande à l'utilisateur de saisir des mots me paraît
pas mal : on balance tout de suite iostream, string et vector, et on
obtient quelque chose de très différent, et beaucoup plus simple, que
ce qui se ferait en C.
On Wed, 22 Feb 2006 19:29:20 +0000 (UTC), Marc Boyer :
C'est donc un cours fait pour des programmeurs C ?
C'était tellement implicite que je n'ai pas eut à le dire ;-)
Si les élèves connaissent déjà le C, on peut passer rapidement sur les trucs de base (notion de variable, de fonction), et surtout aborder très rapidement des notions qui n'existent pas en C (string, vector, fonctions membres, etc.), histoire de leur montrer qu'on parle d'un langage fondamentalement différent, et pas d'une simple extension au C.
Un programme qui demande à l'utilisateur de saisir des mots me paraît pas mal : on balance tout de suite iostream, string et vector, et on obtient quelque chose de très différent, et beaucoup plus simple, que ce qui se ferait en C.
Fabien LE LEZ
On Wed, 22 Feb 2006 19:22:46 +0000 (UTC), Marc Boyer :
Il y a un certain nombre de fonctionnalités plutôt simples, et reprises dans pas mal de langages.
Oui, mais à quoi penses tu ?
À la même chose que toi, vraisemblablement...
Ce sur quoi je voulais insister, c'est la progression.
Par exemple :
Partie I ... c) vector ... e) notion de classe (variables et fonctions membres) ... m) notion de template ...
Partie II ... c) Si on ajoute un élément dans un vector, les itérateurs sont invalidés ... e) fonctions membres virtuelles ... m) spécialisations de templates ...
Partie III ... c) - algorithmes tordus - quand utiliser list à la place de vector ... e) type statique vs type dynamique (ou "pourquoi les fonctions membres virtuelles merdoient dans un constructeur") ... m) bizarreries du Koenig-lookup avec les templates ...
Ce plan est bien sûr bidon ; ce que je veux montrer, c'est qu'on peut/doit montrer d'abord les aspects simples des diverses fonctionnalités, puis, pour chacune, monter progressivement dans les subtilités et la difficulté.
On Wed, 22 Feb 2006 19:22:46 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
Il y a un certain nombre de fonctionnalités plutôt simples, et
reprises dans pas mal de langages.
Oui, mais à quoi penses tu ?
À la même chose que toi, vraisemblablement...
Ce sur quoi je voulais insister, c'est la progression.
Par exemple :
Partie I
...
c) vector
...
e) notion de classe (variables et fonctions membres)
...
m) notion de template
...
Partie II
...
c) Si on ajoute un élément dans un vector, les itérateurs sont
invalidés
...
e) fonctions membres virtuelles
...
m) spécialisations de templates
...
Partie III
...
c) - algorithmes tordus
- quand utiliser list à la place de vector
...
e) type statique vs type dynamique (ou "pourquoi les fonctions
membres virtuelles merdoient dans un constructeur")
...
m) bizarreries du Koenig-lookup avec les templates
...
Ce plan est bien sûr bidon ; ce que je veux montrer, c'est qu'on
peut/doit montrer d'abord les aspects simples des diverses
fonctionnalités, puis, pour chacune, monter progressivement dans les
subtilités et la difficulté.
On Wed, 22 Feb 2006 19:22:46 +0000 (UTC), Marc Boyer :
Il y a un certain nombre de fonctionnalités plutôt simples, et reprises dans pas mal de langages.
Oui, mais à quoi penses tu ?
À la même chose que toi, vraisemblablement...
Ce sur quoi je voulais insister, c'est la progression.
Par exemple :
Partie I ... c) vector ... e) notion de classe (variables et fonctions membres) ... m) notion de template ...
Partie II ... c) Si on ajoute un élément dans un vector, les itérateurs sont invalidés ... e) fonctions membres virtuelles ... m) spécialisations de templates ...
Partie III ... c) - algorithmes tordus - quand utiliser list à la place de vector ... e) type statique vs type dynamique (ou "pourquoi les fonctions membres virtuelles merdoient dans un constructeur") ... m) bizarreries du Koenig-lookup avec les templates ...
Ce plan est bien sûr bidon ; ce que je veux montrer, c'est qu'on peut/doit montrer d'abord les aspects simples des diverses fonctionnalités, puis, pour chacune, monter progressivement dans les subtilités et la difficulté.
Fabien LE LEZ
On Thu, 23 Feb 2006 15:56:36 +0000 (UTC), Marc Boyer :
Bon, après, la gestion des erreurs dans le format d'entrée, je pense que c'est pénible dans les deux langages.
Pour le coup, j'en viens à me demander si c'est pas pire en C++.
On Thu, 23 Feb 2006 15:56:36 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
Bon, après, la gestion des erreurs dans le format d'entrée,
je pense que c'est pénible dans les deux langages.
Pour le coup, j'en viens à me demander si c'est pas pire en C++.
On Thu, 23 Feb 2006 15:56:36 +0000 (UTC), Marc Boyer :
Bon, après, la gestion des erreurs dans le format d'entrée, je pense que c'est pénible dans les deux langages.
Pour le coup, j'en viens à me demander si c'est pas pire en C++.
Fabien LE LEZ
On 23 Feb 2006 01:09:20 -0800, "kanze" :
(sinon qu'il faut parler de std:: -- mais dans un premier temps, c'est juste une convention de nommage un peu particulière, qui touche string et cout).
Et qu'on peut balayer d'un revers du "using".
On 23 Feb 2006 01:09:20 -0800, "kanze" <kanze@gabi-soft.fr>:
(sinon qu'il faut parler de std:: -- mais dans
un premier temps, c'est juste une convention de nommage un peu
particulière, qui touche string et cout).
(sinon qu'il faut parler de std:: -- mais dans un premier temps, c'est juste une convention de nommage un peu particulière, qui touche string et cout).
Et qu'on peut balayer d'un revers du "using".
Marc Boyer
Le 23-02-2006, Fabien LE LEZ a écrit :
On Thu, 23 Feb 2006 15:56:36 +0000 (UTC), Marc Boyer :
Bon, après, la gestion des erreurs dans le format d'entrée, je pense que c'est pénible dans les deux langages.
Pour le coup, j'en viens à me demander si c'est pas pire en C++.
Je me demande. Je suis pas expert. En C, un coup de fgets + scanf, et scanf disant combien de conversions il a réussit à faire, je vois à peut prêt comment faire. En C++, faut tester l'état du flux à chaque fois, non ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 23-02-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
On Thu, 23 Feb 2006 15:56:36 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
Bon, après, la gestion des erreurs dans le format d'entrée,
je pense que c'est pénible dans les deux langages.
Pour le coup, j'en viens à me demander si c'est pas pire en C++.
Je me demande. Je suis pas expert.
En C, un coup de fgets + scanf, et scanf disant combien
de conversions il a réussit à faire, je vois à peut prêt
comment faire.
En C++, faut tester l'état du flux à chaque fois, non ?
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling
On Thu, 23 Feb 2006 15:56:36 +0000 (UTC), Marc Boyer :
Bon, après, la gestion des erreurs dans le format d'entrée, je pense que c'est pénible dans les deux langages.
Pour le coup, j'en viens à me demander si c'est pas pire en C++.
Je me demande. Je suis pas expert. En C, un coup de fgets + scanf, et scanf disant combien de conversions il a réussit à faire, je vois à peut prêt comment faire. En C++, faut tester l'état du flux à chaque fois, non ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Fabien LE LEZ
On 23 Feb 2006 00:36:04 -0800, "kanze" :
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.
On peut dire la même chose de PHP, ou de bien d'autres langages.
Mais si on commence tout de suite par un truc très simple à faire en C++ mais très compliqué en C, ça devrait suffire à bien marquer que C++ n'est pas C.
Du style, utiliser "std::string::operator+" plusieurs fois dans une boucle.
On 23 Feb 2006 00:36:04 -0800, "kanze" <kanze@gabi-soft.fr>:
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.
On peut dire la même chose de PHP, ou de bien d'autres langages.
Mais si on commence tout de suite par un truc très simple à faire en
C++ mais très compliqué en C, ça devrait suffire à bien marquer que
C++ n'est pas C.
Du style, utiliser "std::string::operator+" plusieurs fois dans une
boucle.
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.
On peut dire la même chose de PHP, ou de bien d'autres langages.
Mais si on commence tout de suite par un truc très simple à faire en C++ mais très compliqué en C, ça devrait suffire à bien marquer que C++ n'est pas C.
Du style, utiliser "std::string::operator+" plusieurs fois dans une boucle.
Fabien LE LEZ
On Thu, 23 Feb 2006 10:39:44 +0100, Laurent Deniau :
basics, ca doit rester basique! Le but c'est de se familiarise avec la syntaxe, le processus de compilation, les mot clefs, etc... Pas de larguer les etudiants.
Penses-tu que le deuxième morceau de code ci-dessous soit plus compliqué que le premier ?
On Thu, 23 Feb 2006 10:39:44 +0100, Laurent Deniau
<laurent.deniau@cern.ch>:
basics, ca doit rester basique! Le but c'est de se familiarise avec la
syntaxe, le processus de compilation, les mot clefs, etc... Pas de
larguer les etudiants.
Penses-tu que le deuxième morceau de code ci-dessous soit plus
compliqué que le premier ?
On Thu, 23 Feb 2006 10:39:44 +0100, Laurent Deniau :
basics, ca doit rester basique! Le but c'est de se familiarise avec la syntaxe, le processus de compilation, les mot clefs, etc... Pas de larguer les etudiants.
Penses-tu que le deuxième morceau de code ci-dessous soit plus compliqué que le premier ?
