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
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 C++ on ne distingue pas.
Si, voir la différence entre fail et bad.
Toutes mes sources disent : -- fail : flux consistant ; -- bad : flux non consistant, en particulier erreur bas niveau.
Je suis d'accord avec elle. fail: erreur de format, bad: erreur dans le fichier. bad va etre mis dans les cas ou fgets aurais renvoye une erreur (et pas simplement signale la fin du fichier), fail dans les cas ou sscanf aurait renvoye une erreur.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Franck Branjonneau <fasbjx@free.fr> writes:
Jean-Marc Bourguet <jm@bourguet.org> écrivait:
Franck Branjonneau <fasbjx@free.fr> writes:
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 C++ on ne distingue pas.
Si, voir la différence entre fail et bad.
Toutes mes sources disent :
-- fail : flux consistant ;
-- bad : flux non consistant, en particulier erreur bas niveau.
Je suis d'accord avec elle. fail: erreur de format, bad: erreur dans
le fichier. bad va etre mis dans les cas ou fgets aurais renvoye une
erreur (et pas simplement signale la fin du fichier), fail dans les
cas ou sscanf aurait renvoye une erreur.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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 C++ on ne distingue pas.
Si, voir la différence entre fail et bad.
Toutes mes sources disent : -- fail : flux consistant ; -- bad : flux non consistant, en particulier erreur bas niveau.
Je suis d'accord avec elle. fail: erreur de format, bad: erreur dans le fichier. bad va etre mis dans les cas ou fgets aurais renvoye une erreur (et pas simplement signale la fin du fichier), fail dans les cas ou sscanf aurait renvoye une erreur.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
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 ?
On peut remplacer le ',' dans le champs du scanf par un %c avec test que %c vaut ','.
Dans la pratique, je l'ai souvent trouvé suffisant d'indiquer le nom du fichier et le numéro de ligne.
Je n'ai pas vraiment d'idée sur l'intérêt de cela. Je ne sais pas quelle est le degrès de qualité 'suffisant' pour un code professionnel. J'ai même peur que ce soit assez variable...
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).
Oui, quel niveau de qualité est attendu ? De loin, j'avais l'impression qu'il est fréquent qu'un utilisateur oublie un séparateur, se plante dans l'ordre des champs ou autre chose. Entrer un entier supérieur à 2^31, je ne sais pas.
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.
OK
-- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 25-02-2006, James Kanze <kanze.james@neuf.fr> a écrit :
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 ?
On peut remplacer le ',' dans le champs du scanf par un %c
avec test que %c vaut ','.
Dans la pratique, je l'ai souvent trouvé suffisant d'indiquer
le nom du fichier et le numéro de ligne.
Je n'ai pas vraiment d'idée sur l'intérêt de cela.
Je ne sais pas quelle est le degrès de qualité 'suffisant'
pour un code professionnel. J'ai même peur que ce soit
assez variable...
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).
Oui, quel niveau de qualité est attendu ?
De loin, j'avais l'impression qu'il est fréquent qu'un utilisateur
oublie un séparateur, se plante dans l'ordre des champs ou autre
chose. Entrer un entier supérieur à 2^31, je ne sais pas.
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.
OK
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling
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 ?
On peut remplacer le ',' dans le champs du scanf par un %c avec test que %c vaut ','.
Dans la pratique, je l'ai souvent trouvé suffisant d'indiquer le nom du fichier et le numéro de ligne.
Je n'ai pas vraiment d'idée sur l'intérêt de cela. Je ne sais pas quelle est le degrès de qualité 'suffisant' pour un code professionnel. J'ai même peur que ce soit assez variable...
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).
Oui, quel niveau de qualité est attendu ? De loin, j'avais l'impression qu'il est fréquent qu'un utilisateur oublie un séparateur, se plante dans l'ordre des champs ou autre chose. Entrer un entier supérieur à 2^31, je ne sais pas.
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.
OK
-- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Marc Boyer
Le 25-02-2006, Franck Branjonneau a écrit :
Marc Boyer écrivait:
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 C++ on ne distingue pas. Tu auras, par exemple,
in >> date;
et en cas d'échec in.fail() est true.
C'est bien ce que je disais: il faut tester à chaque fois.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 25-02-2006, Franck Branjonneau <fasbjx@free.fr> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> écrivait:
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 C++ on ne distingue pas.
Tu auras, par exemple,
in >> date;
et en cas d'échec in.fail() est true.
C'est bien ce que je disais: il faut tester à chaque fois.
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 C++ on ne distingue pas. Tu auras, par exemple,
in >> date;
et en cas d'échec in.fail() est true.
C'est bien ce que je disais: il faut tester à chaque fois.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Marc Boyer
Le 24-02-2006, Fabien LE LEZ a écrit :
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" ?
Oui, c'est en général la réponse que je fais. Mais ça pose le problème d'enseigner C++ à des gens qui ne sont pas sensibilisés aux problèmes qu'il cherche à résoudre. En gros, ça prend du temps...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Le 24-02-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
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"...
Et c'est quoi, "assez grand" ?
Oui, c'est en général la réponse que je fais.
Mais ça pose le problème d'enseigner C++ à des gens
qui ne sont pas sensibilisés aux problèmes qu'il
cherche à résoudre.
En gros, ça prend du temps...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling
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" ?
Oui, c'est en général la réponse que je fais. Mais ça pose le problème d'enseigner C++ à des gens qui ne sont pas sensibilisés aux problèmes qu'il cherche à résoudre. En gros, ça prend du temps...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling
Alexandre
"Marc Boyer" a écrit dans le message de news:
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++.
c'est un cours de "C++" ou un cours "d'algo" ou un cours de "programmation" ou un cours de "programmation système" ou un cours de "programmation objet" ;-)
AMA la réponse orientera l'ordre des "couches" à traiter dans ton cours ;-)
Moi j'enseigne le C++ pas dans un cours de C++, mais dans un cours de prog, le C++ me sert de langage support (bien pratique il peut illustrer pas mal de concepts différents)
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrndvo8gn.9ld.Marc.Boyer@localhost.localdomain...
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++.
c'est un cours de "C++" ou un cours "d'algo" ou un cours de "programmation"
ou un cours de "programmation système" ou un cours de "programmation objet"
;-)
AMA la réponse orientera l'ordre des "couches" à traiter dans ton cours ;-)
Moi j'enseigne le C++ pas dans un cours de C++, mais dans un cours de prog,
le C++ me sert de langage support (bien pratique il peut illustrer pas mal
de concepts différents)
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++.
c'est un cours de "C++" ou un cours "d'algo" ou un cours de "programmation" ou un cours de "programmation système" ou un cours de "programmation objet" ;-)
AMA la réponse orientera l'ordre des "couches" à traiter dans ton cours ;-)
Moi j'enseigne le C++ pas dans un cours de C++, mais dans un cours de prog, le C++ me sert de langage support (bien pratique il peut illustrer pas mal de concepts différents)
Marc Boyer
Le 28-02-2006, Alexandre a écrit :
"Marc Boyer" a écrit dans le message de news:
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++.
c'est un cours de "C++" ou un cours "d'algo" ou un cours de "programmation" ou un cours de "programmation système" ou un cours de "programmation objet" ;-)
Il est parfois difficile d'avoir exactement le cahier des charges. C'est un cours qui viens après un cours de C.
AMA la réponse orientera l'ordre des "couches" à traiter dans ton cours ;-)
Oui.
Moi j'enseigne le C++ pas dans un cours de C++, mais dans un cours de prog, le C++ me sert de langage support (bien pratique il peut illustrer pas mal de concepts différents)
Oui.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 28-02-2006, Alexandre <alex.g@netcourrier.com> a écrit :
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrndvo8gn.9ld.Marc.Boyer@localhost.localdomain...
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++.
c'est un cours de "C++" ou un cours "d'algo" ou un cours de "programmation"
ou un cours de "programmation système" ou un cours de "programmation objet"
;-)
Il est parfois difficile d'avoir exactement le cahier des charges.
C'est un cours qui viens après un cours de C.
AMA la réponse orientera l'ordre des "couches" à traiter dans ton cours ;-)
Oui.
Moi j'enseigne le C++ pas dans un cours de C++, mais dans un cours de prog,
le C++ me sert de langage support (bien pratique il peut illustrer pas mal
de concepts différents)
Oui.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
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++.
c'est un cours de "C++" ou un cours "d'algo" ou un cours de "programmation" ou un cours de "programmation système" ou un cours de "programmation objet" ;-)
Il est parfois difficile d'avoir exactement le cahier des charges. C'est un cours qui viens après un cours de C.
AMA la réponse orientera l'ordre des "couches" à traiter dans ton cours ;-)
Oui.
Moi j'enseigne le C++ pas dans un cours de C++, mais dans un cours de prog, le C++ me sert de langage support (bien pratique il peut illustrer pas mal de concepts différents)
Oui.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
