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
Bien que. Il y a peut-être un rapport de cause à effet, mais il ne m'intéresse pas ici ; je voulais juste rappeler que la difficulté d'implémentation des templates n'empêche pas cette fonctionnalité d'être facile à utiliser.
A mon avis, la même analogie tient en mettant les termes C et C++.
Non. Une interface GUI simplifie l'utilisation (des débutants), mais a aussi tendance à réduire les possibilités. Alors que C++ est plus facile à utiliser, tout en étant au moins aussi puissant.
On Thu, 23 Feb 2006 22:00:30 +0100, Loïc Joly :
"Bien que" ou "c'est pourquoi" ?
Bien que. Il y a peut-être un rapport de cause à effet, mais il ne
m'intéresse pas ici ; je voulais juste rappeler que la difficulté
d'implémentation des templates n'empêche pas cette fonctionnalité
d'être facile à utiliser.
A mon avis, la même analogie tient en mettant les termes C et C++.
Non. Une interface GUI simplifie l'utilisation (des débutants), mais a
aussi tendance à réduire les possibilités.
Alors que C++ est plus facile à utiliser, tout en étant au moins aussi
puissant.
Bien que. Il y a peut-être un rapport de cause à effet, mais il ne m'intéresse pas ici ; je voulais juste rappeler que la difficulté d'implémentation des templates n'empêche pas cette fonctionnalité d'être facile à utiliser.
A mon avis, la même analogie tient en mettant les termes C et C++.
Non. Une interface GUI simplifie l'utilisation (des débutants), mais a aussi tendance à réduire les possibilités. Alors que C++ est plus facile à utiliser, tout en étant au moins aussi puissant.
Marc Boyer
Le 23-02-2006, Franck Branjonneau a écrit :
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.
Non, je voulais parler "d'erreur dans le /format/ d'entrée" et pas dans le fichier d'entrée.
En ce moment, je lis un fichier avec des lignes du genre NAME, 22, A, 500, 1500, ON avec getline/fgets, je peux lire la ligne en entier, et détecter la fin de ligne. Mais s'il y a une erreur dans le format (oublis de virgule, oublis d'un champs), comment le tester ? Avec la valeur de retour de sscanf, on peut relativement facilement gérer les erreurs avec un truc du genre (non testé: faudrait que je revérifie s).
if (scan_res != FIELD_NB) { fprintf(stderr, "Parse error:" " impossible to read field %s (%d th)", field_name[scan_res], scan_res+1); return -1; // Ou un truc du genre }
En C++, je ne sais pas comment faire cela sans mettre 6 'if (...)' les uns à la suite des autres (hormis à prendre un sscanf).
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, Franck Branjonneau <fasbjx@free.fr> a écrit :
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.
Non, je voulais parler "d'erreur dans le /format/
d'entrée" et pas dans le fichier d'entrée.
En ce moment, je lis un fichier avec des lignes
du genre
NAME, 22, A, 500, 1500, ON
avec getline/fgets, je peux lire la ligne en entier, et
détecter la fin de ligne. Mais s'il y a une erreur
dans le format (oublis de virgule, oublis d'un champs),
comment le tester ?
Avec la valeur de retour de sscanf, on peut relativement
facilement gérer les erreurs avec un truc du genre
(non testé: faudrait que je revérifie s).
if (scan_res != FIELD_NB) {
fprintf(stderr, "Parse error:"
" impossible to read field %s (%d th)",
field_name[scan_res], scan_res+1);
return -1; // Ou un truc du genre
}
En C++, je ne sais pas comment faire cela sans
mettre 6 'if (...)' les uns à la suite des autres
(hormis à prendre un sscanf).
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 ?
Autant de fois que tu testes le retour de fgets en C.
Non, je voulais parler "d'erreur dans le /format/ d'entrée" et pas dans le fichier d'entrée.
En ce moment, je lis un fichier avec des lignes du genre NAME, 22, A, 500, 1500, ON avec getline/fgets, je peux lire la ligne en entier, et détecter la fin de ligne. Mais s'il y a une erreur dans le format (oublis de virgule, oublis d'un champs), comment le tester ? Avec la valeur de retour de sscanf, on peut relativement facilement gérer les erreurs avec un truc du genre (non testé: faudrait que je revérifie s).
if (scan_res != FIELD_NB) { fprintf(stderr, "Parse error:" " impossible to read field %s (%d th)", field_name[scan_res], scan_res+1); return -1; // Ou un truc du genre }
En C++, je ne sais pas comment faire cela sans mettre 6 'if (...)' les uns à la suite des autres (hormis à prendre un sscanf).
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Marc Boyer
Le 23-02-2006, Loïc Joly 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)
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...
J'avoue que j'ai un peut peur de dire "regardez, C++ c'est génial, on peut écrire string s; getline(cin, s); sans se soucier de la taille max de la ligne" et de m'entendre répondre "ben, en C, suffit de faire un scanf("%s") avec un buffer assez grand"...
Enfin bon, j'y suis pas encore.
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, Loïc Joly <loic.actarus.joly@numericable.fr> 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)
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...
J'avoue que j'ai un peut peur de dire
"regardez, C++ c'est génial, on peut écrire
string s;
getline(cin, s);
sans se soucier de la taille max de la ligne"
et de m'entendre répondre
"ben, en C, suffit de faire un scanf("%s") avec un
buffer assez grand"...
Enfin bon, j'y suis pas encore.
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)
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...
J'avoue que j'ai un peut peur de dire "regardez, C++ c'est génial, on peut écrire string s; getline(cin, s); sans se soucier de la taille max de la ligne" et de m'entendre répondre "ben, en C, suffit de faire un scanf("%s") avec un buffer assez grand"...
Enfin bon, j'y suis pas encore.
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 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é.
Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon mes observations) commencer par les templates plus facilement acceptes conceptuellement par les debutants *puis* passer au polymorphisme d'heritage.
Ceci dit, la complexite de l'implementation reflete aussi parfois la complexite de l'utilisation, pas d'un point de vue conceptuel, mais plutot dans des contextes complexes qui ne devraient pas etre l'objet d'un cours pour debutant.
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.
Ca ca reste a voir. Le novice peut mettre pas mal de temps pour decouvrir que ce qu'il cherche a faire est possible en mettant la souris sur le petit carre pres de la regle droite et d'appuyer simultanement sur bouton souris-droit+controle-gauche+shift-gauche +drag et de relacher le tout sur le petit rond pres de la pomme rouge en bas a gauche et tout ca a condition que l'interface soit en mode pouet2.
a+, ld.
Fabien LE LEZ wrote:
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é.
Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon mes
observations) commencer par les templates plus facilement acceptes
conceptuellement par les debutants *puis* passer au polymorphisme
d'heritage.
Ceci dit, la complexite de l'implementation reflete aussi parfois la
complexite de l'utilisation, pas d'un point de vue conceptuel, mais
plutot dans des contextes complexes qui ne devraient pas etre l'objet
d'un cours pour debutant.
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.
Ca ca reste a voir. Le novice peut mettre pas mal de temps pour
decouvrir que ce qu'il cherche a faire est possible en mettant la souris
sur le petit carre pres de la regle droite et d'appuyer simultanement
sur bouton souris-droit+controle-gauche+shift-gauche +drag et de
relacher le tout sur le petit rond pres de la pomme rouge en bas a
gauche et tout ca a condition que l'interface soit en mode pouet2.
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é.
Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon mes observations) commencer par les templates plus facilement acceptes conceptuellement par les debutants *puis* passer au polymorphisme d'heritage.
Ceci dit, la complexite de l'implementation reflete aussi parfois la complexite de l'utilisation, pas d'un point de vue conceptuel, mais plutot dans des contextes complexes qui ne devraient pas etre l'objet d'un cours pour debutant.
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.
Ca ca reste a voir. Le novice peut mettre pas mal de temps pour decouvrir que ce qu'il cherche a faire est possible en mettant la souris sur le petit carre pres de la regle droite et d'appuyer simultanement sur bouton souris-droit+controle-gauche+shift-gauche +drag et de relacher le tout sur le petit rond pres de la pomme rouge en bas a gauche et tout ca a condition que l'interface soit en mode pouet2.
a+, ld.
Gabriel Dos Reis
Laurent Deniau writes:
| Fabien LE LEZ wrote: | > 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é. | | Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon | mes observations) commencer par les templates plus facilement acceptes | conceptuellement par les debutants *puis* passer au polymorphisme | d'heritage.
100% agreed.
-- Gaby
Laurent Deniau <laurent.deniau@cern.ch> writes:
| Fabien LE LEZ wrote:
| > 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é.
|
| Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon
| mes observations) commencer par les templates plus facilement acceptes
| conceptuellement par les debutants *puis* passer au polymorphisme
| d'heritage.
| Fabien LE LEZ wrote: | > 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é. | | Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon | mes observations) commencer par les templates plus facilement acceptes | conceptuellement par les debutants *puis* passer au polymorphisme | d'heritage.
100% agreed.
-- Gaby
Fabien LE LEZ
On Fri, 24 Feb 2006 08:02:58 +0000 (UTC), Marc Boyer :
"ben, en C, suffit de faire un scanf("%s") avec un buffer assez grand"...
Et c'est quoi, "assez grand" ?
On Fri, 24 Feb 2006 08:02:58 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
"ben, en C, suffit de faire un scanf("%s") avec un
buffer assez grand"...
des notions qui n'existent pas en C (string, vector, fonctions membres, etc.),
On peut mettre des fonctions dans des struct en C.
--
Etienne
James Kanze
Marc Boyer wrote:
Marc Boyer écrivait:
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.
Non, je voulais parler "d'erreur dans le /format/ d'entrée" et pas dans le fichier d'entrée.
En ce moment, je lis un fichier avec des lignes du genre NAME, 22, A, 500, 1500, ON avec getline/fgets, je peux lire la ligne en entier, et détecter la fin de ligne. Mais s'il y a une erreur dans le format (oublis de virgule, oublis d'un champs), comment le tester ? Avec la valeur de retour de sscanf, on peut relativement facilement gérer les erreurs avec un truc du genre (non testé: faudrait que je revérifie s).
if (scan_res != FIELD_NB) { fprintf(stderr, "Parse error:" " impossible to read field %s (%d th)", field_name[scan_res], scan_res+1); return -1; // Ou un truc du genre }
En C++, je ne sais pas comment faire cela sans mettre 6 'if (...)' les uns à la suite des autres (hormis à prendre un sscanf).
Mais est-ce réelement intéressant ? Parce que si j'oublie un virgule, dans quel champs est-ce que l'erreur se trouve réelement ?
Dans la pratique, je l'ai souvent trouvé suffisant d'indiquer le nom du fichier et le numéro de ligne. Si je veux plus, c'est plus compliqué, aussi bien avec sscanf qu'avec istringstream -- par exemple, ni l'un ni l'autre n'ont un comportement défini en cas de débordement d'un champs numérique (genre 1000000000000000 comme entrée pour un int à 32 bits). Dans ces cas-là, j'utilise beaucoup boost::regex ou Gabi::FieldArray pour obtenir les champs. Ensuite, je convertis les champs numérique au moyen de strtol ou strtof, qui eux ont un comportement défini dans ces cas-là, et qui permet à indiquer bien si le problème est due au débordement, ou à une erreur de format, genre caractère non numérique.
-- James Kanze 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
Marc Boyer wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> écrivait:
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.
Non, je voulais parler "d'erreur dans le /format/
d'entrée" et pas dans le fichier d'entrée.
En ce moment, je lis un fichier avec des lignes
du genre
NAME, 22, A, 500, 1500, ON
avec getline/fgets, je peux lire la ligne en entier, et
détecter la fin de ligne. Mais s'il y a une erreur
dans le format (oublis de virgule, oublis d'un champs),
comment le tester ?
Avec la valeur de retour de sscanf, on peut relativement
facilement gérer les erreurs avec un truc du genre
(non testé: faudrait que je revérifie s).
if (scan_res != FIELD_NB) {
fprintf(stderr, "Parse error:"
" impossible to read field %s (%d th)",
field_name[scan_res], scan_res+1);
return -1; // Ou un truc du genre
}
En C++, je ne sais pas comment faire cela sans mettre 6 'if
(...)' les uns à la suite des autres (hormis à prendre un
sscanf).
Mais est-ce réelement intéressant ? Parce que si j'oublie un
virgule, dans quel champs est-ce que l'erreur se trouve
réelement ?
Dans la pratique, je l'ai souvent trouvé suffisant d'indiquer
le nom du fichier et le numéro de ligne. Si je veux plus, c'est
plus compliqué, aussi bien avec sscanf qu'avec istringstream --
par exemple, ni l'un ni l'autre n'ont un comportement défini en
cas de débordement d'un champs numérique (genre 1000000000000000
comme entrée pour un int à 32 bits). Dans ces cas-là, j'utilise
beaucoup boost::regex ou Gabi::FieldArray pour obtenir les
champs. Ensuite, je convertis les champs numérique au moyen de
strtol ou strtof, qui eux ont un comportement défini dans ces
cas-là, et qui permet à indiquer bien si le problème est due au
débordement, ou à une erreur de format, genre caractère non
numérique.
--
James Kanze kanze.james@neuf.fr
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 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.
Non, je voulais parler "d'erreur dans le /format/ d'entrée" et pas dans le fichier d'entrée.
En ce moment, je lis un fichier avec des lignes du genre NAME, 22, A, 500, 1500, ON avec getline/fgets, je peux lire la ligne en entier, et détecter la fin de ligne. Mais s'il y a une erreur dans le format (oublis de virgule, oublis d'un champs), comment le tester ? Avec la valeur de retour de sscanf, on peut relativement facilement gérer les erreurs avec un truc du genre (non testé: faudrait que je revérifie s).
if (scan_res != FIELD_NB) { fprintf(stderr, "Parse error:" " impossible to read field %s (%d th)", field_name[scan_res], scan_res+1); return -1; // Ou un truc du genre }
En C++, je ne sais pas comment faire cela sans mettre 6 'if (...)' les uns à la suite des autres (hormis à prendre un sscanf).
Mais est-ce réelement intéressant ? Parce que si j'oublie un virgule, dans quel champs est-ce que l'erreur se trouve réelement ?
Dans la pratique, je l'ai souvent trouvé suffisant d'indiquer le nom du fichier et le numéro de ligne. Si je veux plus, c'est plus compliqué, aussi bien avec sscanf qu'avec istringstream -- par exemple, ni l'un ni l'autre n'ont un comportement défini en cas de débordement d'un champs numérique (genre 1000000000000000 comme entrée pour un int à 32 bits). Dans ces cas-là, j'utilise beaucoup boost::regex ou Gabi::FieldArray pour obtenir les champs. Ensuite, je convertis les champs numérique au moyen de strtol ou strtof, qui eux ont un comportement défini dans ces cas-là, et qui permet à indiquer bien si le problème est due au débordement, ou à une erreur de format, genre caractère non numérique.
-- James Kanze 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
James Kanze
Etienne Rousee wrote:
"Fabien LE LEZ" a écrit ...
des notions qui n'existent pas en C (string, vector, fonctions membres, etc.),
On peut mettre des fonctions dans des struct en C.
Depuis quand ? Ce n'est pas dans C99.
-- James Kanze 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
Etienne Rousee wrote:
"Fabien LE LEZ" <gramster@gramster.com> a écrit ...
des notions qui n'existent pas en C (string, vector,
fonctions membres, etc.),
On peut mettre des fonctions dans des struct en C.
Depuis quand ? Ce n'est pas dans C99.
--
James Kanze kanze.james@neuf.fr
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
des notions qui n'existent pas en C (string, vector, fonctions membres, etc.),
On peut mettre des fonctions dans des struct en C.
Depuis quand ? Ce n'est pas dans C99.
-- James Kanze 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
James Kanze
Laurent Deniau wrote:
Fabien LE LEZ wrote:
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é.
Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon mes observations) commencer par les templates plus facilement acceptes conceptuellement par les debutants *puis* passer au polymorphisme d'heritage.
Dans quelle mésure ? Je suis assez d'accord pour les templates ancienne modèle, que le néophyte considérait un peu comme un espèce de macro. Mais je me vois mal expliquer la récherche de nom en deux phases à un débuttant.
De toute façon, j'aime l'approche que tu as suggéré ailleurs. Plutôt que d'enseigner l'héritage en tant que tel, on a une leçon sur, disons, le modèle de stratégie. L'héritage est alors présenté comme une solution à un problème réel -- l'élève voit d'abord ce dont il a besoin, et ensuite, la solution C++.
Je dirais que la même chose vaut pour les templates : plutôt que d'enseigner les templates, on enseigne comment écrire une collection. Avec l'exigeance que je puisse dire le type que le collection doit contenir, et que le compilateur râle si je ne le répecte pas. Ensuite, on montre la solution C++, avec les explications qu'il faut.
-- James Kanze 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 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é.
Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux
(selon mes observations) commencer par les templates plus
facilement acceptes conceptuellement par les debutants *puis*
passer au polymorphisme d'heritage.
Dans quelle mésure ? Je suis assez d'accord pour les templates
ancienne modèle, que le néophyte considérait un peu comme un
espèce de macro. Mais je me vois mal expliquer la récherche de
nom en deux phases à un débuttant.
De toute façon, j'aime l'approche que tu as suggéré ailleurs.
Plutôt que d'enseigner l'héritage en tant que tel, on a une
leçon sur, disons, le modèle de stratégie. L'héritage est alors
présenté comme une solution à un problème réel -- l'élève voit
d'abord ce dont il a besoin, et ensuite, la solution C++.
Je dirais que la même chose vaut pour les templates : plutôt que
d'enseigner les templates, on enseigne comment écrire une
collection. Avec l'exigeance que je puisse dire le type que le
collection doit contenir, et que le compilateur râle si je ne
le répecte pas. Ensuite, on montre la solution C++, avec les
explications qu'il faut.
--
James Kanze kanze.james@neuf.fr
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 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é.
Dans ce cas tu devrais relire ce que j'ai dit: il vaut mieux (selon mes observations) commencer par les templates plus facilement acceptes conceptuellement par les debutants *puis* passer au polymorphisme d'heritage.
Dans quelle mésure ? Je suis assez d'accord pour les templates ancienne modèle, que le néophyte considérait un peu comme un espèce de macro. Mais je me vois mal expliquer la récherche de nom en deux phases à un débuttant.
De toute façon, j'aime l'approche que tu as suggéré ailleurs. Plutôt que d'enseigner l'héritage en tant que tel, on a une leçon sur, disons, le modèle de stratégie. L'héritage est alors présenté comme une solution à un problème réel -- l'élève voit d'abord ce dont il a besoin, et ensuite, la solution C++.
Je dirais que la même chose vaut pour les templates : plutôt que d'enseigner les templates, on enseigne comment écrire une collection. Avec l'exigeance que je puisse dire le type que le collection doit contenir, et que le compilateur râle si je ne le répecte pas. Ensuite, on montre la solution C++, avec les explications qu'il faut.
-- James Kanze 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
