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 16:11:11 +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.
[...]
En C, un coup de fgets + scanf
sscanf
Oui, mon clavier à fourché. Heureusement, le compilo détecte en général quand je fais ce genre d'erreur.
En C++, faut tester l'état du flux à chaque fois, non ?
J'avoue que je ne sais pas. Si je dois lire un istream, j'utilise uniquement getline(), puis je parse à la main. Parfois avec sscanf, d'ailleurs.
Le couteau suisse, ça a du bon parfois ;-)
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Laurent Deniau
Fabien LE LEZ wrote:
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.
D'abord BS dit lui-meme dans le D&E que l'implementation des templates lui a pose plus de probleme que l'heritage multiple ou le polymorphisme d'heritage, contrairement a ce que la communaute C++ pensait a cette epoque. Et je le crois sur parole.
Ensuite, tout ce qui est lookup est souvent complique par nature, du moins plus qu'un simple ajustement d'offset et un appel indirect. Ce qui peut rendre complique le polymorphisme d'heritage en presence d'heritage multiple (avec l'heritage simple c'est trivial), c'est les optimisations aggressives des compilateurs pour obtenir le meilleur compromis rapidite-du-code/taille-des-instances.
Si tu prends le lookup avec l'overloading, les namespaces, les classes (derived, nested, local), l'accessibilite, les fonctions, les operateurs, les fonctions membres, les usings, les friends, l'operateur de resolution, les declarations, les definitions, les conversions (implicite, user-defined), les promotions, les traits, c'est deja passablement complique (du moins pour ma petite tete). Rajoute la dessus l'impact des templates et leurs specialisations pour chaque combinaison de ces points et je pense que ca devient ce que j'appelerais complique. Je pense que ceux qui ecrivent les routines de lookup, meme si elle sont clairement definie dans la norme, ne participent pas a la partie la plus facile de l'implementation du langage.
Reste aussi a considerer les concepts-check qui essaye de verifier que tout ce que tu as ecrit et la facon dont tu l'utilises tiens debout et correspond a ce qui a ete prevu.
a+, ld.
Fabien LE LEZ wrote:
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.
D'abord BS dit lui-meme dans le D&E que l'implementation des templates
lui a pose plus de probleme que l'heritage multiple ou le polymorphisme
d'heritage, contrairement a ce que la communaute C++ pensait a cette
epoque. Et je le crois sur parole.
Ensuite, tout ce qui est lookup est souvent complique par nature, du
moins plus qu'un simple ajustement d'offset et un appel indirect. Ce qui
peut rendre complique le polymorphisme d'heritage en presence d'heritage
multiple (avec l'heritage simple c'est trivial), c'est les optimisations
aggressives des compilateurs pour obtenir le meilleur compromis
rapidite-du-code/taille-des-instances.
Si tu prends le lookup avec l'overloading, les namespaces, les classes
(derived, nested, local), l'accessibilite, les fonctions, les
operateurs, les fonctions membres, les usings, les friends, l'operateur
de resolution, les declarations, les definitions, les conversions
(implicite, user-defined), les promotions, les traits, c'est deja
passablement complique (du moins pour ma petite tete). Rajoute la dessus
l'impact des templates et leurs specialisations pour chaque combinaison
de ces points et je pense que ca devient ce que j'appelerais complique.
Je pense que ceux qui ecrivent les routines de lookup, meme si elle sont
clairement definie dans la norme, ne participent pas a la partie la plus
facile de l'implementation du langage.
Reste aussi a considerer les concepts-check qui essaye de verifier que
tout ce que tu as ecrit et la facon dont tu l'utilises tiens debout et
correspond a ce qui a ete prevu.
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.
D'abord BS dit lui-meme dans le D&E que l'implementation des templates lui a pose plus de probleme que l'heritage multiple ou le polymorphisme d'heritage, contrairement a ce que la communaute C++ pensait a cette epoque. Et je le crois sur parole.
Ensuite, tout ce qui est lookup est souvent complique par nature, du moins plus qu'un simple ajustement d'offset et un appel indirect. Ce qui peut rendre complique le polymorphisme d'heritage en presence d'heritage multiple (avec l'heritage simple c'est trivial), c'est les optimisations aggressives des compilateurs pour obtenir le meilleur compromis rapidite-du-code/taille-des-instances.
Si tu prends le lookup avec l'overloading, les namespaces, les classes (derived, nested, local), l'accessibilite, les fonctions, les operateurs, les fonctions membres, les usings, les friends, l'operateur de resolution, les declarations, les definitions, les conversions (implicite, user-defined), les promotions, les traits, c'est deja passablement complique (du moins pour ma petite tete). Rajoute la dessus l'impact des templates et leurs specialisations pour chaque combinaison de ces points et je pense que ca devient ce que j'appelerais complique. Je pense que ceux qui ecrivent les routines de lookup, meme si elle sont clairement definie dans la norme, ne participent pas a la partie la plus facile de l'implementation du langage.
Reste aussi a considerer les concepts-check qui essaye de verifier que tout ce que tu as ecrit et la facon dont tu l'utilises tiens debout et correspond a ce qui a ete prevu.
a+, ld.
Franck Branjonneau
Marc Boyer écrivait:
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 ?
Autant de fois que tu testes le retour de fgets en C. À chaque fois ? ;-)
-- Franck
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> écrivait:
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 ?
Autant de fois que tu testes le retour de fgets en C.
À chaque fois ? ;-)
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 ?
Autant de fois que tu testes le retour de fgets en C. À chaque fois ? ;-)
-- Franck
Fabien LE LEZ
On Thu, 23 Feb 2006 18:38:01 +0100, Franck Branjonneau :
Autant de fois que tu testes le retour de fgets en C.
Mauvais exemple AMHA. Typiquement, fgets() et getline() s'utilisent en boucle, et le code de retour est testé pour arrêter la boucle.
Celui qui devrait être testé systématiquement et ne l'est pas, c'est (s)scanf.
On Thu, 23 Feb 2006 18:38:01 +0100, Franck Branjonneau
<fasbjx@free.fr>:
Autant de fois que tu testes le retour de fgets en C.
Mauvais exemple AMHA. Typiquement, fgets() et getline() s'utilisent en
boucle, et le code de retour est testé pour arrêter la boucle.
Celui qui devrait être testé systématiquement et ne l'est pas, c'est
(s)scanf.
On Thu, 23 Feb 2006 18:38:01 +0100, Franck Branjonneau :
Autant de fois que tu testes le retour de fgets en C.
Mauvais exemple AMHA. Typiquement, fgets() et getline() s'utilisent en boucle, et le code de retour est testé pour arrêter la boucle.
Celui qui devrait être testé systématiquement et ne l'est pas, c'est (s)scanf.
Fabien LE LEZ
On Thu, 23 Feb 2006 17:56:24 +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.
D'abord BS dit lui-meme dans le D&E que l'implementation des templates [...]
Ah, OK, tu parles de l'implémentation. Je m'intéressais quant à moi à l'accès d'un débutant à une fonctionnalité.
Une interface GUI (notamment pour un OS) est plus facile à utiliser qu'une interface "console" pour un débutant, bien qu'elle soit plus compliquée à implémenter.
On Thu, 23 Feb 2006 17:56:24 +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.
D'abord BS dit lui-meme dans le D&E que l'implementation des templates [...]
Ah, OK, tu parles de l'implémentation. Je m'intéressais quant à moi à
l'accès d'un débutant à une fonctionnalité.
Une interface GUI (notamment pour un OS) est plus facile à utiliser
qu'une interface "console" pour un débutant, bien qu'elle soit plus
compliquée à implémenter.
On Thu, 23 Feb 2006 17:56:24 +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.
D'abord BS dit lui-meme dans le D&E que l'implementation des templates [...]
Ah, OK, tu parles de l'implémentation. Je m'intéressais quant à moi à l'accès d'un débutant à une fonctionnalité.
Une interface GUI (notamment pour un OS) est plus facile à utiliser qu'une interface "console" pour un débutant, bien qu'elle soit plus compliquée à implémenter.
Jean-Marc Desperrier
Marc Boyer wrote:
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. Tu peux t'inspirer de ce qui existe.
J'ai de vagues souvenirs de terminale (ou prépa ?). Tout circuit ayant une capacité et une résistance équivalente... Faut voir.
Arf !! Ca me fait réagir ça.
Je ne sais pas si vous savez que la traduction française du Stroutrup a une erreur de traduction grandiose reliée exactement à cela :-) (en tout cas l'édition d'il y a quelques années, ça a peut-être été corrigé dans une réédition).
Il y a un petit exemple qui traîne au début du bouquin qui calcule l'amortissement d'un circuit capacité/résistance.
Sauf que le traducteur français qui visiblement n'a jamais touché à l'électronique :-) a séché sur "damping" (amortissement), et plutôt que d'ouvrir son Harrap est parti dans l'exotique en parlant de calculer la valeur de l'"humidité" du circuit. Ca devrait beaucoup faire rire tes élèves.
Marc Boyer wrote:
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.
Tu peux t'inspirer de ce qui existe.
J'ai de vagues souvenirs de terminale (ou prépa ?). Tout circuit
ayant une capacité et une résistance équivalente... Faut voir.
Arf !! Ca me fait réagir ça.
Je ne sais pas si vous savez que la traduction française du Stroutrup a
une erreur de traduction grandiose reliée exactement à cela :-) (en tout
cas l'édition d'il y a quelques années, ça a peut-être été corrigé dans
une réédition).
Il y a un petit exemple qui traîne au début du bouquin qui calcule
l'amortissement d'un circuit capacité/résistance.
Sauf que le traducteur français qui visiblement n'a jamais touché à
l'électronique :-) a séché sur "damping" (amortissement), et plutôt que
d'ouvrir son Harrap est parti dans l'exotique en parlant de calculer la
valeur de l'"humidité" du circuit. Ca devrait beaucoup faire rire tes
élèves.
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. Tu peux t'inspirer de ce qui existe.
J'ai de vagues souvenirs de terminale (ou prépa ?). Tout circuit ayant une capacité et une résistance équivalente... Faut voir.
Arf !! Ca me fait réagir ça.
Je ne sais pas si vous savez que la traduction française du Stroutrup a une erreur de traduction grandiose reliée exactement à cela :-) (en tout cas l'édition d'il y a quelques années, ça a peut-être été corrigé dans une réédition).
Il y a un petit exemple qui traîne au début du bouquin qui calcule l'amortissement d'un circuit capacité/résistance.
Sauf que le traducteur français qui visiblement n'a jamais touché à l'électronique :-) a séché sur "damping" (amortissement), et plutôt que d'ouvrir son Harrap est parti dans l'exotique en parlant de calculer la valeur de l'"humidité" du circuit. Ca devrait beaucoup faire rire tes élèves.
Franck Branjonneau
Fabien LE LEZ écrivait:
On Thu, 23 Feb 2006 18:38:01 +0100, Franck Branjonneau :
Autant de fois que tu testes le retour de fgets en C.
Mauvais exemple AMHA. Typiquement, fgets() et getline() s'utilisent en boucle, et le code de retour est testé pour arrêter la boucle.
Comprends pas. En C++ tu fais un test par getline, en C un test par fgets -- ça en fait autant non ?
-- Franck Branjonneau
Fabien LE LEZ <gramster@gramster.com> écrivait:
On Thu, 23 Feb 2006 18:38:01 +0100, Franck Branjonneau
<fasbjx@free.fr>:
Autant de fois que tu testes le retour de fgets en C.
Mauvais exemple AMHA. Typiquement, fgets() et getline() s'utilisent en
boucle, et le code de retour est testé pour arrêter la boucle.
Comprends pas. En C++ tu fais un test par getline, en C un test par
fgets -- ça en fait autant non ?
On Thu, 23 Feb 2006 18:38:01 +0100, Franck Branjonneau :
Autant de fois que tu testes le retour de fgets en C.
Mauvais exemple AMHA. Typiquement, fgets() et getline() s'utilisent en boucle, et le code de retour est testé pour arrêter la boucle.
Comprends pas. En C++ tu fais un test par getline, en C un test par fgets -- ça en fait autant non ?
-- Franck Branjonneau
Loïc Joly
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)
Bof, j'ai du faire récemment un cours de C++ à des gens connaissant le C, je me suis basé dessus, et en pratique, ils ne le connaissaient pas vraiment...
-- Loï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)
Bof, j'ai du faire récemment un cours de C++ à des gens connaissant le
C, je me suis basé dessus, et en pratique, ils ne le connaissaient pas
vraiment...
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)
Bof, j'ai du faire récemment un cours de C++ à des gens connaissant le C, je me suis basé dessus, et en pratique, ils ne le connaissaient pas vraiment...
-- Loïc
Loïc Joly
Ah, OK, tu parles de l'implémentation. Je m'intéressais quant à moi à l'accès d'un débutant à une fonctionnalité.
Une interface GUI (notamment pour un OS) est plus facile à utiliser qu'une interface "console" pour un débutant, bien qu'elle soit plus compliquée à implémenter.
"Bien que" ou "c'est pourquoi" ?
A mon avis, la même analogie tient en mettant les termes C et C++.
-- Loïc
Ah, OK, tu parles de l'implémentation. Je m'intéressais quant à moi à
l'accès d'un débutant à une fonctionnalité.
Une interface GUI (notamment pour un OS) est plus facile à utiliser
qu'une interface "console" pour un débutant, bien qu'elle soit plus
compliquée à implémenter.
"Bien que" ou "c'est pourquoi" ?
A mon avis, la même analogie tient en mettant les termes C et C++.
Ah, OK, tu parles de l'implémentation. Je m'intéressais quant à moi à l'accès d'un débutant à une fonctionnalité.
Une interface GUI (notamment pour un OS) est plus facile à utiliser qu'une interface "console" pour un débutant, bien qu'elle soit plus compliquée à implémenter.
"Bien que" ou "c'est pourquoi" ?
A mon avis, la même analogie tient en mettant les termes C et C++.
