Voilà... je suis super débutant... Je poste ici mon premier programme
fait maison....
Je voudrait avoir votre avis..
J'utilise Xcode sur un macintosh sous 10.4.4, mais cela n'a pas beaucoup
d'importance...
#include <stdio.h>
#include <string.h>
int main (int argc, const char * argv[]) {
//on défini les variables
char Nom[200];
float quantite; // la variable quantité
float prix; // la variable prix
float total; // la variable total
float tauxtva; // le taux de tva
float soustotal; // le sous tatal sans la tva
float tva; // le montant de la tva
printf("Entrez votre nom : ");
scanf("%s", Nom);
printf("\n");
printf("Taux de tva ? : "); // on demande le taux de tva
scanf("%f",&tauxtva);
printf("\n");
printf("Quantite de l'article a facturer ? : "); // on demande
la quantité
scanf("%f",&quantite);
printf("\n");
printf("Le prix de l'article ? : "); // on demande le prix
scanf("%f",&prix);
printf("\n");
Et de tout facon j'utilise eassert qui a le meme comportement que a ssert (et eassert.h que assert.h) mais leve une exception ExBadAssert en cas d'echec au lieu de quitter le programme.
Pour pouvoir faire quelque chose une fois que l'exception est attrapee, il faut etre sur d'au moins une partie de l'etat du programme. De quelle partie de l'etat es-tu sur apres qu'une assertion echoue? Si tu as l'equivalent des destructeurs, comment ceux-ci peuvent ils etre sur que l'etat des objets qu'ils doivent detruire, ils ne connaissent pas la cause pour laquelle ils sont appeles.
C'est un vaste sujet! [snip des choses interessantes auxquelles je fais faire une
seconde reponse]
Tu ne reponds pas au fond de ma question qui portait sur l'etat que tu supposais valide apres qu'une *assertion* echoue.
Si. Mais a la lecture de ta prose, je crois qu'on a un approche differente des assertions-exceptions. J'utilise les assertions-exceptions exclusivement pour verifier des pre-conditions. Pour les invariants ou les post-conditions j'utilise des assertions-debug.
J'utilise des assertions pour verifier que mes hypotheses sur l'etat du programme sont vraies. Si elles ne sont pas vraies, je me demande ce que je peux encore supposer et faire de sense avant de quitter.
C'est la que l'approche est differente. Je considere le code correcte par defaut (parce que debugge et teste ;-) ) mais je ne fais pas confiance aux entrees. L'etat est donc connu en cas d'echec puisque non affecte par les entrees invalides. Un cas typique, c'est realloc.
Le plus souvent, la cause de l'echec est un defaut d'analyse: l'etat est valide mais le programme n'est pas prevu pour traiter ce cas la. Mais il n'est pas rare qu'on se retrouve avec un etat invalide, soit que l'hypothese a ete tenue pour vraie avant, soit qu'il y a une erreur dans le programme.
Ni l'un, ni l'autre qui normalement auraient du etre revele par les tests. L'utilisateur n'a pas suivi les specs. Les deux premiers cas sont traites pendant les tests et la je suis d'accord qu'a part faire du log et quitter il n'y a pas grand chose d'autre a faire. Ceci dit, meme si c'est pour quitter, les exceptions permettent de detruire les objets existants et de liberer proprement les ressources. Je n'ai que trois cas ou je fait un abort en OOC et ce sont les memes que C++. Il doit y avoir une bonne raison ;-)
Pour etre honnete, mes assertions-debugs restent aussi en production si elle ne penalise pas l'efficacite et me permettent via les logs de savoir ce qui n'a pas fonctionne correctement, mes programmes n'etant biensur pas inffaillibles. Mais en 8 ans, je n'ai eu a le faire que trois fois.
a+, ld.
Laurent.Deniau@gmail.com writes:
Laurent Deniau <laurent.deniau@cern.ch> writes:
Et de tout facon j'utilise eassert qui a le meme comportement que a ssert
(et eassert.h que assert.h) mais leve une exception ExBadAssert en cas
d'echec au lieu de quitter le programme.
Pour pouvoir faire quelque chose une fois que l'exception est
attrapee, il faut etre sur d'au moins une partie de l'etat du
programme. De quelle partie de l'etat es-tu sur apres qu'une
assertion echoue? Si tu as l'equivalent des destructeurs, comment
ceux-ci peuvent ils etre sur que l'etat des objets qu'ils doivent
detruire, ils ne connaissent pas la cause pour laquelle ils sont
appeles.
C'est un vaste sujet!
[snip des choses interessantes auxquelles je fais faire une
seconde reponse]
Tu ne reponds pas au fond de ma question qui portait sur
l'etat que tu supposais valide apres qu'une *assertion*
echoue.
Si. Mais a la lecture de ta prose, je crois qu'on a un approche
differente des assertions-exceptions. J'utilise les
assertions-exceptions exclusivement pour verifier des pre-conditions.
Pour les invariants ou les post-conditions j'utilise des
assertions-debug.
J'utilise des assertions pour verifier que mes hypotheses
sur l'etat du programme sont vraies. Si elles ne sont pas
vraies, je me demande ce que je peux encore supposer et
faire de sense avant de quitter.
C'est la que l'approche est differente. Je considere le code correcte
par defaut (parce que debugge et teste ;-) ) mais je ne fais pas
confiance aux entrees. L'etat est donc connu en cas d'echec puisque non
affecte par les entrees invalides. Un cas typique, c'est realloc.
Le plus souvent, la cause de l'echec est un defaut
d'analyse: l'etat est valide mais le programme n'est pas
prevu pour traiter ce cas la. Mais il n'est pas rare qu'on
se retrouve avec un etat invalide, soit que l'hypothese a
ete tenue pour vraie avant, soit qu'il y a une erreur dans
le programme.
Ni l'un, ni l'autre qui normalement auraient du etre revele par les
tests. L'utilisateur n'a pas suivi les specs. Les deux premiers cas
sont traites pendant les tests et la je suis d'accord qu'a part faire
du log et quitter il n'y a pas grand chose d'autre a faire. Ceci dit,
meme si c'est pour quitter, les exceptions permettent de detruire les
objets existants et de liberer proprement les ressources. Je n'ai que
trois cas ou je fait un abort en OOC et ce sont les memes que C++. Il
doit y avoir une bonne raison ;-)
Pour etre honnete, mes assertions-debugs restent aussi en production si
elle ne penalise pas l'efficacite et me permettent via les logs de
savoir ce qui n'a pas fonctionne correctement, mes programmes n'etant
biensur pas inffaillibles. Mais en 8 ans, je n'ai eu a le faire que
trois fois.
Et de tout facon j'utilise eassert qui a le meme comportement que a ssert (et eassert.h que assert.h) mais leve une exception ExBadAssert en cas d'echec au lieu de quitter le programme.
Pour pouvoir faire quelque chose une fois que l'exception est attrapee, il faut etre sur d'au moins une partie de l'etat du programme. De quelle partie de l'etat es-tu sur apres qu'une assertion echoue? Si tu as l'equivalent des destructeurs, comment ceux-ci peuvent ils etre sur que l'etat des objets qu'ils doivent detruire, ils ne connaissent pas la cause pour laquelle ils sont appeles.
C'est un vaste sujet! [snip des choses interessantes auxquelles je fais faire une
seconde reponse]
Tu ne reponds pas au fond de ma question qui portait sur l'etat que tu supposais valide apres qu'une *assertion* echoue.
Si. Mais a la lecture de ta prose, je crois qu'on a un approche differente des assertions-exceptions. J'utilise les assertions-exceptions exclusivement pour verifier des pre-conditions. Pour les invariants ou les post-conditions j'utilise des assertions-debug.
J'utilise des assertions pour verifier que mes hypotheses sur l'etat du programme sont vraies. Si elles ne sont pas vraies, je me demande ce que je peux encore supposer et faire de sense avant de quitter.
C'est la que l'approche est differente. Je considere le code correcte par defaut (parce que debugge et teste ;-) ) mais je ne fais pas confiance aux entrees. L'etat est donc connu en cas d'echec puisque non affecte par les entrees invalides. Un cas typique, c'est realloc.
Le plus souvent, la cause de l'echec est un defaut d'analyse: l'etat est valide mais le programme n'est pas prevu pour traiter ce cas la. Mais il n'est pas rare qu'on se retrouve avec un etat invalide, soit que l'hypothese a ete tenue pour vraie avant, soit qu'il y a une erreur dans le programme.
Ni l'un, ni l'autre qui normalement auraient du etre revele par les tests. L'utilisateur n'a pas suivi les specs. Les deux premiers cas sont traites pendant les tests et la je suis d'accord qu'a part faire du log et quitter il n'y a pas grand chose d'autre a faire. Ceci dit, meme si c'est pour quitter, les exceptions permettent de detruire les objets existants et de liberer proprement les ressources. Je n'ai que trois cas ou je fait un abort en OOC et ce sont les memes que C++. Il doit y avoir une bonne raison ;-)
Pour etre honnete, mes assertions-debugs restent aussi en production si elle ne penalise pas l'efficacite et me permettent via les logs de savoir ce qui n'a pas fonctionne correctement, mes programmes n'etant biensur pas inffaillibles. Mais en 8 ans, je n'ai eu a le faire que trois fois.
a+, ld.
Gabriel Dos Reis
candide writes:
[...]
| J'ajoute que le rôle pédagogique du debugger est largement sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas passer des heures sous le debugger jusqu'à ce que le programme semble afficher une résultat qui correspond vaguement à la spécification.
Pourquoi ne fais-tu pas un site exempte des reproches que tu fais à Marc et que tu pourrais conseiller aux débutants qui auraient des problèmes que tu soulèves ; cela serait une contribution positive sans précédent.
-- Gaby
candide <candide@domain.invalid> writes:
[...]
| J'ajoute que le rôle pédagogique du debugger est largement sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas
passer des heures sous le debugger jusqu'à ce que le programme semble
afficher une résultat qui correspond vaguement à la spécification.
Pourquoi ne fais-tu pas un site exempte des reproches que tu fais à
Marc et que tu pourrais conseiller aux débutants qui auraient des
problèmes que tu soulèves ; cela serait une contribution positive sans
précédent.
| J'ajoute que le rôle pédagogique du debugger est largement sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas passer des heures sous le debugger jusqu'à ce que le programme semble afficher une résultat qui correspond vaguement à la spécification.
Pourquoi ne fais-tu pas un site exempte des reproches que tu fais à Marc et que tu pourrais conseiller aux débutants qui auraient des problèmes que tu soulèves ; cela serait une contribution positive sans précédent.
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| Chaque argument de type -Wxxx demande au compilo d'activer certains | avertissements. La doc dit exactement lequel fait quoi. | -W en active certains, -Wall d'autres, et en plus, certains | sont communs je crois.
et d'autres activés par -Wextra n'ont pas de nom propre.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Chaque argument de type -Wxxx demande au compilo d'activer certains
| avertissements. La doc dit exactement lequel fait quoi.
| -W en active certains, -Wall d'autres, et en plus, certains
| sont communs je crois.
et d'autres activés par -Wextra n'ont pas de nom propre.
| Chaque argument de type -Wxxx demande au compilo d'activer certains | avertissements. La doc dit exactement lequel fait quoi. | -W en active certains, -Wall d'autres, et en plus, certains | sont communs je crois.
et d'autres activés par -Wextra n'ont pas de nom propre.
-- Gaby
candide
Gabriel Dos Reis wrote in news::
candide writes:
[...]
| J'ajoute que le rôle pédagogique du debugger est largement | sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas passer des heures sous le debugger jusqu'à ce que le programme semble afficher une résultat qui correspond vaguement à la spécification.
Oui j'avais lu sur les archives de Google une discussion où tu défendais ce point de vue. Tu auras noté que j'ai parlé du rôle *pédagogique* du debugger, pour le reste je ne me prononce pas je ne suis pas compétent. Peut-être aussi qu'utiliser un debugger c'est apprendre à s'en passer.
Pourquoi ne fais-tu pas un site exempte des reproches que tu fais à Marc et que tu pourrais conseiller aux débutants qui auraient des problèmes que tu soulèves ; cela serait une contribution positive sans précédent.
Je suis candide alors je fais l'hypothèse que tu n'es pas ironique. Toujours est-il qu'effectivement à terme j'ai l'intention de faire un site pour les débutants comme moi qui sont des très neuneus très motivés dans l'apprentissage du langage C [concernant ce que disait Marc, c'est plus la question de la doc sous Unix/Linux qui était en cause que la question du C à proprement parler, mais là c'est un domaine beaucoup beaucoup plus vaste]. Naturellement, j'ai pour l'instant une vision d'utilisateur du C. Pour moi, l'apprentissage du C ne se réduit pas au C pur, crystallin et éthéré dont il serait question ici. Faire du C c'est aussi une question aussi une question d'environnement au sens large, donc d'éditeur, de débugger, d'outils et de capacités spécifiques (make, outils memoire, inclusion d'assembleur, connaître les options de son compilateur, etc, je vais en découvrir des quantités au fur et à mesure que j'apprendrai), ça peut aussi être occasionnellement une question d'implémentation. J'aurais aussi envie de mettre une grosse partie à faire du codage en C de questions mathématiques (tout en restant simple, il existe des dizaines de sujets intéressants propres à satisfaire le matheux amateur ou non même si le C n'est pas forcément le langage le plus adapté). Je le ferai parce que la doc que je vois ne me donne absolument pas satisfaction, et en même temps me semble TRES largement perfectible et en plus assez _facilement_, c'est juste une question de temps et de motivation (les idées elles suivent après sans sans problème) et je ne manque ni de l'un ni de l'autre. Et j'ai bien l'intention de faire quelque chose qui n'existe pas, oui, sinon autant ne rien faire. Mais auparavant, il m'aura fallu beaucoup lire, beaucoup coder, beaucoup expérimenter, beaucoup réfléchir, beaucoup discuter, beaucoup tester. En disant cela, j'ai bien conscience que j'en ai pris pour 5 ans. En espérant qu'à ce moment-là, on programmera encore en C tant qu'à faire (merci de me rassurer sinon je passe à Java ;) )
Sur ce je crois que je vais vous faire un nouvel "ce n'est qu'un au revoir" parce que vous avez compris que j'ai du code sur la planche, et je suis sérieux.
Candide
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in
news:m3y80rxhyg.fsf@uniton.integrable-solutions.net:
candide <candide@domain.invalid> writes:
[...]
| J'ajoute que le rôle pédagogique du debugger est largement
| sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas
passer des heures sous le debugger jusqu'à ce que le programme semble
afficher une résultat qui correspond vaguement à la spécification.
Oui j'avais lu sur les archives de Google une discussion où tu défendais
ce point de vue. Tu auras noté que j'ai parlé du rôle *pédagogique* du
debugger, pour le reste je ne me prononce pas je ne suis pas compétent.
Peut-être aussi qu'utiliser un debugger c'est apprendre à s'en passer.
Pourquoi ne fais-tu pas un site exempte des reproches que tu fais à
Marc et que tu pourrais conseiller aux débutants qui auraient des
problèmes que tu soulèves ; cela serait une contribution positive sans
précédent.
Je suis candide alors je fais l'hypothèse que tu n'es pas ironique.
Toujours est-il qu'effectivement à terme j'ai l'intention de faire un
site pour les débutants comme moi qui sont des très neuneus très motivés
dans l'apprentissage du langage C [concernant ce que disait Marc, c'est
plus la question de la doc sous Unix/Linux qui était en cause que la
question du C à proprement parler, mais là c'est un domaine beaucoup
beaucoup plus vaste]. Naturellement, j'ai pour l'instant une vision
d'utilisateur du C. Pour moi, l'apprentissage du C ne se réduit pas au C
pur, crystallin et éthéré dont il serait question ici. Faire du C c'est
aussi une question aussi une question d'environnement au sens large, donc
d'éditeur, de débugger, d'outils et de capacités spécifiques (make,
outils memoire, inclusion d'assembleur, connaître les options de son
compilateur, etc, je vais en découvrir des quantités au fur et à mesure
que j'apprendrai), ça peut aussi être occasionnellement une question
d'implémentation. J'aurais aussi envie de mettre une grosse partie à
faire du codage en C de questions mathématiques
(tout en restant simple, il existe des dizaines de sujets intéressants
propres à satisfaire le matheux amateur ou non même si le C n'est pas
forcément le langage le plus adapté). Je le ferai parce que la doc que je
vois ne me donne absolument pas satisfaction, et en même temps me semble
TRES largement perfectible et en plus assez _facilement_, c'est juste une
question de temps et de motivation (les idées elles suivent après sans
sans problème) et je ne manque ni de l'un ni de l'autre. Et j'ai bien
l'intention de faire quelque chose qui n'existe pas, oui, sinon autant ne
rien faire. Mais auparavant, il m'aura fallu beaucoup lire, beaucoup
coder, beaucoup expérimenter, beaucoup réfléchir, beaucoup discuter,
beaucoup tester. En disant cela, j'ai bien conscience que j'en ai pris
pour 5 ans. En espérant qu'à ce moment-là, on programmera encore en C
tant qu'à faire (merci de me rassurer sinon je passe à Java ;) )
Sur ce je crois que je vais vous faire un nouvel "ce n'est qu'un au
revoir" parce que vous avez compris que j'ai du code sur la planche, et
je suis sérieux.
| J'ajoute que le rôle pédagogique du debugger est largement | sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas passer des heures sous le debugger jusqu'à ce que le programme semble afficher une résultat qui correspond vaguement à la spécification.
Oui j'avais lu sur les archives de Google une discussion où tu défendais ce point de vue. Tu auras noté que j'ai parlé du rôle *pédagogique* du debugger, pour le reste je ne me prononce pas je ne suis pas compétent. Peut-être aussi qu'utiliser un debugger c'est apprendre à s'en passer.
Pourquoi ne fais-tu pas un site exempte des reproches que tu fais à Marc et que tu pourrais conseiller aux débutants qui auraient des problèmes que tu soulèves ; cela serait une contribution positive sans précédent.
Je suis candide alors je fais l'hypothèse que tu n'es pas ironique. Toujours est-il qu'effectivement à terme j'ai l'intention de faire un site pour les débutants comme moi qui sont des très neuneus très motivés dans l'apprentissage du langage C [concernant ce que disait Marc, c'est plus la question de la doc sous Unix/Linux qui était en cause que la question du C à proprement parler, mais là c'est un domaine beaucoup beaucoup plus vaste]. Naturellement, j'ai pour l'instant une vision d'utilisateur du C. Pour moi, l'apprentissage du C ne se réduit pas au C pur, crystallin et éthéré dont il serait question ici. Faire du C c'est aussi une question aussi une question d'environnement au sens large, donc d'éditeur, de débugger, d'outils et de capacités spécifiques (make, outils memoire, inclusion d'assembleur, connaître les options de son compilateur, etc, je vais en découvrir des quantités au fur et à mesure que j'apprendrai), ça peut aussi être occasionnellement une question d'implémentation. J'aurais aussi envie de mettre une grosse partie à faire du codage en C de questions mathématiques (tout en restant simple, il existe des dizaines de sujets intéressants propres à satisfaire le matheux amateur ou non même si le C n'est pas forcément le langage le plus adapté). Je le ferai parce que la doc que je vois ne me donne absolument pas satisfaction, et en même temps me semble TRES largement perfectible et en plus assez _facilement_, c'est juste une question de temps et de motivation (les idées elles suivent après sans sans problème) et je ne manque ni de l'un ni de l'autre. Et j'ai bien l'intention de faire quelque chose qui n'existe pas, oui, sinon autant ne rien faire. Mais auparavant, il m'aura fallu beaucoup lire, beaucoup coder, beaucoup expérimenter, beaucoup réfléchir, beaucoup discuter, beaucoup tester. En disant cela, j'ai bien conscience que j'en ai pris pour 5 ans. En espérant qu'à ce moment-là, on programmera encore en C tant qu'à faire (merci de me rassurer sinon je passe à Java ;) )
Sur ce je crois que je vais vous faire un nouvel "ce n'est qu'un au revoir" parce que vous avez compris que j'ai du code sur la planche, et je suis sérieux.
Candide
Jean-Marc Bourguet
candide writes:
abstraite. Ce n'est pas pour rien qu'un des bouquins de Hennessy et Patterson est sous-titre "The Hardware/Software Interface".
Merci, je viens de regarder la toc, ça déchire.
Je n'ai pas lu celui la mais le sous-titre marque bien le point que je voulais faire. Je ne sais pas quelles bases il demande. J'ai l'autre (Computer Architecture, A Quantitative Approach qui est plus complet, a certains endroits ils renvoient a Computer Organisation and Design pour une explication des principes qu'ils utilisent) qui n'est a coup sur pas un bouquin d'introduction.
-- Jean-Marc
candide <candide@domain.invalid> writes:
abstraite. Ce n'est pas pour rien qu'un des bouquins de
Hennessy et Patterson est sous-titre "The Hardware/Software
Interface".
Merci, je viens de regarder la toc, ça déchire.
Je n'ai pas lu celui la mais le sous-titre marque bien le
point que je voulais faire. Je ne sais pas quelles bases il
demande. J'ai l'autre (Computer Architecture, A
Quantitative Approach qui est plus complet, a certains
endroits ils renvoient a Computer Organisation and Design
pour une explication des principes qu'ils utilisent) qui
n'est a coup sur pas un bouquin d'introduction.
abstraite. Ce n'est pas pour rien qu'un des bouquins de Hennessy et Patterson est sous-titre "The Hardware/Software Interface".
Merci, je viens de regarder la toc, ça déchire.
Je n'ai pas lu celui la mais le sous-titre marque bien le point que je voulais faire. Je ne sais pas quelles bases il demande. J'ai l'autre (Computer Architecture, A Quantitative Approach qui est plus complet, a certains endroits ils renvoient a Computer Organisation and Design pour une explication des principes qu'ils utilisent) qui n'est a coup sur pas un bouquin d'introduction.
-- Jean-Marc
candide
Marc Boyer wrote in news::
Chaque argument de type -Wxxx demande au compilo d'activer certains
donc xxx peut être vide
avertissements. La doc dit exactement lequel fait quoi. -W en active certains, -Wall d'autres, et en plus, certains sont communs je crois.
Tu vois bien que c'est pas du tout intuitif (je suppose que c'est une
histoire de compatibilité entre versions successives de gcc)
Je souligne que ne connais pas cette liste par coeur, je sais juste par tatonnenements
oui oui la question n'est pas là bien sûr.
successifs que, pour mon code, je compile avec -W -Wall -pedantic -stdÉ9 et que cela me conviens bien. Et quand je travaille avec le code des élèves, j'ajoute -Wuninitialized -0
OK
C'est pour cela que, même si je pense que mes cours sont de qualité, je ne me lance pas à écrire le N+1 ième bouquin de C...
Et pourtant, ce ne doit pas tre très dur, la capacité première étant de savoir faire un tri topologique.
J'avoue aussi que, considérant que tu avais une agreg de math, j'ai du mal à situer ton niveau: les questions que tu poses vont bien plus loins que ce que se posent mes étudiants, et je t'imaginais plus apte à lire des docs informatiques.
Question : Qu'est ce qu'il faut pour comprendre la doc ? Réponse : Comprendre la doc.
Candide
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in
news:slrndu9cvc.46u.Marc.Boyer@localhost.localdomain:
Chaque argument de type -Wxxx demande au compilo d'activer certains
donc xxx peut être vide
avertissements. La doc dit exactement lequel fait quoi.
-W en active certains, -Wall d'autres, et en plus, certains
sont communs je crois.
Tu vois bien que c'est pas du tout intuitif (je suppose que c'est une
histoire de compatibilité entre versions successives de gcc)
Je souligne que ne connais
pas cette liste par coeur, je sais juste par tatonnenements
oui oui la question n'est pas là bien sûr.
successifs que, pour mon code, je compile avec
-W -Wall -pedantic -stdÉ9
et que cela me conviens bien.
Et quand je travaille avec le code des élèves, j'ajoute
-Wuninitialized -0
OK
C'est pour cela que, même si je pense que mes cours sont de qualité,
je ne me lance pas à écrire le N+1 ième bouquin de C...
Et pourtant, ce ne doit pas tre très dur, la capacité première étant de
savoir faire un tri topologique.
J'avoue aussi que, considérant que tu avais une agreg de math, j'ai
du
mal à situer ton niveau: les questions que tu poses vont bien plus
loins que ce que se posent mes étudiants, et je t'imaginais plus apte
à lire des docs informatiques.
Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : Comprendre la doc.
Chaque argument de type -Wxxx demande au compilo d'activer certains
donc xxx peut être vide
avertissements. La doc dit exactement lequel fait quoi. -W en active certains, -Wall d'autres, et en plus, certains sont communs je crois.
Tu vois bien que c'est pas du tout intuitif (je suppose que c'est une
histoire de compatibilité entre versions successives de gcc)
Je souligne que ne connais pas cette liste par coeur, je sais juste par tatonnenements
oui oui la question n'est pas là bien sûr.
successifs que, pour mon code, je compile avec -W -Wall -pedantic -stdÉ9 et que cela me conviens bien. Et quand je travaille avec le code des élèves, j'ajoute -Wuninitialized -0
OK
C'est pour cela que, même si je pense que mes cours sont de qualité, je ne me lance pas à écrire le N+1 ième bouquin de C...
Et pourtant, ce ne doit pas tre très dur, la capacité première étant de savoir faire un tri topologique.
J'avoue aussi que, considérant que tu avais une agreg de math, j'ai du mal à situer ton niveau: les questions que tu poses vont bien plus loins que ce que se posent mes étudiants, et je t'imaginais plus apte à lire des docs informatiques.
Question : Qu'est ce qu'il faut pour comprendre la doc ? Réponse : Comprendre la doc.
Candide
candide
candide wrote in news:43e4d94c$0$21277$:
Toujours est-il qu'effectivement à terme j'ai l'intention de faire un site pour les débutants comme moi qui sont des très neuneus très motivés dans l'apprentissage du langage C
Oui, une rubrique à faire aussi c'est une rubrique documentation et en particulier sur les forums. Le nombre d'étudiants de licence d'info qui ne connaissent rien de usenet est hallucinant, alors imaginez les autres. Il faut donc expliquer pas à pas au visiteur neuneu du site qu'il existe cette ressource méconnue qu'est usenet et il faut expliquer pas-à-pas comment on fait pour s'incrire sur un forum, c'est quoi un serveur de news, etc, tout un tas de truc que j'ai mis un temps fou à apprendre parce que si on connait pas quelqu'un qui vous initie, c'est galère de trouver la doc éparse sur le net. Alors c'est sûr, ça n'a aucun rapport avec le langage C mais c'est en rapport avec son apprentissage et en plus ça ne coûte pas cher à expliquer et je pense avoir le temps de le faire.
Et puis, y'aura une rubrique people, les in et les out du Committee et les dernières blaguent qui y courent ;)
Candide
candide <candide@domain.invalid> wrote in
news:43e4d94c$0$21277$8fcfb975@news.wanadoo.fr:
Toujours est-il qu'effectivement à terme j'ai l'intention de faire un
site pour les débutants comme moi qui sont des très neuneus très
motivés dans l'apprentissage du langage C
Oui, une rubrique à faire aussi c'est une rubrique documentation et en
particulier sur les forums. Le nombre d'étudiants de licence d'info qui
ne connaissent rien de usenet est hallucinant, alors imaginez les autres.
Il faut donc expliquer pas à pas au visiteur neuneu du site qu'il existe
cette ressource méconnue qu'est usenet et il faut expliquer pas-à-pas
comment on fait pour s'incrire sur un forum, c'est quoi un serveur de
news, etc, tout un tas de truc que j'ai mis un temps fou à apprendre
parce que si on connait pas quelqu'un qui vous initie, c'est galère de
trouver la doc éparse sur le net. Alors c'est sûr, ça n'a aucun rapport
avec le langage C mais c'est en rapport avec son apprentissage et en plus
ça ne coûte pas cher à expliquer et je pense avoir le temps de le faire.
Et puis, y'aura une rubrique people, les in et les out du Committee et
les dernières blaguent qui y courent ;)
Toujours est-il qu'effectivement à terme j'ai l'intention de faire un site pour les débutants comme moi qui sont des très neuneus très motivés dans l'apprentissage du langage C
Oui, une rubrique à faire aussi c'est une rubrique documentation et en particulier sur les forums. Le nombre d'étudiants de licence d'info qui ne connaissent rien de usenet est hallucinant, alors imaginez les autres. Il faut donc expliquer pas à pas au visiteur neuneu du site qu'il existe cette ressource méconnue qu'est usenet et il faut expliquer pas-à-pas comment on fait pour s'incrire sur un forum, c'est quoi un serveur de news, etc, tout un tas de truc que j'ai mis un temps fou à apprendre parce que si on connait pas quelqu'un qui vous initie, c'est galère de trouver la doc éparse sur le net. Alors c'est sûr, ça n'a aucun rapport avec le langage C mais c'est en rapport avec son apprentissage et en plus ça ne coûte pas cher à expliquer et je pense avoir le temps de le faire.
Et puis, y'aura une rubrique people, les in et les out du Committee et les dernières blaguent qui y courent ;)
Candide
Jean-Marc Bourguet
candide writes:
Gabriel Dos Reis wrote in news::
candide writes:
[...]
| J'ajoute que le rôle pédagogique du debugger est largement | sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas passer des heures sous le debugger jusqu'à ce que le programme semble afficher une résultat qui correspond vaguement à la spécification.
Oui j'avais lu sur les archives de Google une discussion où tu défendais ce point de vue. Tu auras noté que j'ai parlé du rôle *pédagogique* du debugger, pour le reste je ne me prononce pas je ne suis pas compétent. Peut-être aussi qu'utiliser un debugger c'est apprendre à s'en passer.
Apprendre a utiliser une debugger, c'est plutôt apprendre à en être dépendant.
Au fait, quel est l'aspect que tu trouves pédagogique dans l'utilisation d'un debugger?
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
candide <candide@domain.invalid> writes:
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in
news:m3y80rxhyg.fsf@uniton.integrable-solutions.net:
candide <candide@domain.invalid> writes:
[...]
| J'ajoute que le rôle pédagogique du debugger est largement
| sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas
passer des heures sous le debugger jusqu'à ce que le programme semble
afficher une résultat qui correspond vaguement à la spécification.
Oui j'avais lu sur les archives de Google une discussion où tu défendais
ce point de vue. Tu auras noté que j'ai parlé du rôle *pédagogique* du
debugger, pour le reste je ne me prononce pas je ne suis pas compétent.
Peut-être aussi qu'utiliser un debugger c'est apprendre à s'en passer.
Apprendre a utiliser une debugger, c'est plutôt apprendre à
en être dépendant.
Au fait, quel est l'aspect que tu trouves pédagogique dans
l'utilisation d'un debugger?
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
| J'ajoute que le rôle pédagogique du debugger est largement | sous-estimé, un
je trouve que le debugger est sur-estimé. Programmer, ce n'est pas passer des heures sous le debugger jusqu'à ce que le programme semble afficher une résultat qui correspond vaguement à la spécification.
Oui j'avais lu sur les archives de Google une discussion où tu défendais ce point de vue. Tu auras noté que j'ai parlé du rôle *pédagogique* du debugger, pour le reste je ne me prononce pas je ne suis pas compétent. Peut-être aussi qu'utiliser un debugger c'est apprendre à s'en passer.
Apprendre a utiliser une debugger, c'est plutôt apprendre à en être dépendant.
Au fait, quel est l'aspect que tu trouves pédagogique dans l'utilisation d'un debugger?
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
candide writes:
C'est pour cela que, même si je pense que mes cours sont de qualité, je ne me lance pas à écrire le N+1 ième bouquin de C...
Et pourtant, ce ne doit pas tre très dur, la capacité première étant de savoir faire un tri topologique.
Il y a des cycles. S'il n'y en avait pas, tu aurais déjà ce que tu veux.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
candide <candide@domain.invalid> writes:
C'est pour cela que, même si je pense que mes cours
sont de qualité, je ne me lance pas à écrire le N+1 ième
bouquin de C...
Et pourtant, ce ne doit pas tre très dur, la capacité
première étant de savoir faire un tri topologique.
Il y a des cycles. S'il n'y en avait pas, tu aurais déjà ce
que tu veux.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est pour cela que, même si je pense que mes cours sont de qualité, je ne me lance pas à écrire le N+1 ième bouquin de C...
Et pourtant, ce ne doit pas tre très dur, la capacité première étant de savoir faire un tri topologique.
Il y a des cycles. S'il n'y en avait pas, tu aurais déjà ce que tu veux.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
"Laurent Deniau" writes:
OOC supporte seulement l'heritage simple et utilise la delegation de type pour simuler l'heritage multiple. Un objet est structurellement valide (du point de vu OOC) juste apres son *allocation* et avant son initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation neutre pour le destructeur par l'effet de l'allocation. J'avais compris de
si le constructeur commence par rendre son objet neutre pour son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme il faut que toute la hiérarchie soit dans un état neutre pour pouvoir appeler le destructeur, j'imaginais une construction en deux temps.
Si tu as un exemple concis d'heritage simple en C++ qui montre un probleme qui te tiens a coeur, je peux essayer de voir en quoi OOC resout ou non le probleme.
Je n'ai rien de particulier en vue.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
OOC supporte seulement l'heritage simple et utilise la delegation de
type pour simuler l'heritage multiple. Un objet est structurellement
valide (du point de vu OOC) juste apres son *allocation* et avant son
initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation
neutre pour le destructeur par l'effet de l'allocation.
J'avais compris de
si le constructeur commence par rendre son objet neutre pour
son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme
il faut que toute la hiérarchie soit dans un état neutre
pour pouvoir appeler le destructeur, j'imaginais une
construction en deux temps.
Si tu as un exemple concis d'heritage simple en C++ qui
montre un probleme qui te tiens a coeur, je peux essayer
de voir en quoi OOC resout ou non le probleme.
Je n'ai rien de particulier en vue.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
OOC supporte seulement l'heritage simple et utilise la delegation de type pour simuler l'heritage multiple. Un objet est structurellement valide (du point de vu OOC) juste apres son *allocation* et avant son initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation neutre pour le destructeur par l'effet de l'allocation. J'avais compris de
si le constructeur commence par rendre son objet neutre pour son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme il faut que toute la hiérarchie soit dans un état neutre pour pouvoir appeler le destructeur, j'imaginais une construction en deux temps.
Si tu as un exemple concis d'heritage simple en C++ qui montre un probleme qui te tiens a coeur, je peux essayer de voir en quoi OOC resout ou non le probleme.
Je n'ai rien de particulier en vue.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
