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");
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.
J'utilise une lib qui le fait... le résultat est l'équivalent moral de:
} catch (libXException& e) { assert(false); }
Si je ne passe repecte pas les pré-conditions de ce que j'utilise, je ne sais pas quoi faire de sensé dans le programme une fois qu'on me l'a signalé; je ne vois pas ce que ceux qui m'appellent pourraient faire non plus. Par contre, je vois très bien le risque qu'il peut y avoir de laisser croire à l'utilisateur que le programme est dans un état cohérent alors qu'il ne l'est peut être pas.
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 ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans des contextes très différents et que je maîtrise beaucoup moins ce dont je ne m'occupe pas dans le programme que toi.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de l'utilisateur. Ces vérifications doivent être là quoi qu'il passe dans la tête d'un CM, de celui qui reprendra le code, ou des défauts considérés comme adéquats par le fournisseur du compilateur qu'on utilisera dans le futur. Les assertions sont pour moi des commentaires dont la validité est vérifiée à l'exécution, elles ne font pas partie de ce que le programme est sensé faire. Vérifier les entrées de l'utilisateur, le programme doit le faire.
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
Quel est l'intérêt?
de liberer proprement les ressources.
Libérer les ressources qui ne le sont pas par effet de bord d'une fin de programme, je le fais aussi. Elles sont rares dans les OS que j'utilise.
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 ;-)
Ce sont?
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
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.
J'utilise une lib qui le fait... le résultat est
l'équivalent moral de:
} catch (libXException& e) {
assert(false);
}
Si je ne passe repecte pas les pré-conditions de ce que
j'utilise, je ne sais pas quoi faire de sensé dans le
programme une fois qu'on me l'a signalé; je ne vois pas ce
que ceux qui m'appellent pourraient faire non plus. Par
contre, je vois très bien le risque qu'il peut y avoir de
laisser croire à l'utilisateur que le programme est dans un
état cohérent alors qu'il ne l'est peut être pas.
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 ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans
des contextes très différents et que je maîtrise beaucoup
moins ce dont je ne m'occupe pas dans le programme que toi.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de
l'utilisateur. Ces vérifications doivent être là quoi qu'il
passe dans la tête d'un CM, de celui qui reprendra le code,
ou des défauts considérés comme adéquats par le fournisseur
du compilateur qu'on utilisera dans le futur. Les
assertions sont pour moi des commentaires dont la validité
est vérifiée à l'exécution, elles ne font pas partie de ce
que le programme est sensé faire. Vérifier les entrées de
l'utilisateur, le programme doit le faire.
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
Quel est l'intérêt?
de liberer proprement les ressources.
Libérer les ressources qui ne le sont pas par effet de bord
d'une fin de programme, je le fais aussi. Elles sont rares
dans les OS que j'utilise.
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
;-)
Ce sont?
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
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.
J'utilise une lib qui le fait... le résultat est l'équivalent moral de:
} catch (libXException& e) { assert(false); }
Si je ne passe repecte pas les pré-conditions de ce que j'utilise, je ne sais pas quoi faire de sensé dans le programme une fois qu'on me l'a signalé; je ne vois pas ce que ceux qui m'appellent pourraient faire non plus. Par contre, je vois très bien le risque qu'il peut y avoir de laisser croire à l'utilisateur que le programme est dans un état cohérent alors qu'il ne l'est peut être pas.
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 ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans des contextes très différents et que je maîtrise beaucoup moins ce dont je ne m'occupe pas dans le programme que toi.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de l'utilisateur. Ces vérifications doivent être là quoi qu'il passe dans la tête d'un CM, de celui qui reprendra le code, ou des défauts considérés comme adéquats par le fournisseur du compilateur qu'on utilisera dans le futur. Les assertions sont pour moi des commentaires dont la validité est vérifiée à l'exécution, elles ne font pas partie de ce que le programme est sensé faire. Vérifier les entrées de l'utilisateur, le programme doit le faire.
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
Quel est l'intérêt?
de liberer proprement les ressources.
Libérer les ressources qui ne le sont pas par effet de bord d'une fin de programme, je le fais aussi. Elles sont rares dans les OS que j'utilise.
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 ;-)
Ce sont?
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
Gabriel Dos Reis
candide writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
-- Gaby
candide <candide@domain.invalid> writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
-- Gaby
Gabriel Dos Reis
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,
j'ai noté ce que tu as écris, mais je n'ai pas l'impression que tu as lu ce que j'ai écris.
-- Gaby
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,
j'ai noté ce que tu as écris, mais je n'ai pas l'impression que tu as
lu ce que j'ai écris.
| 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,
j'ai noté ce que tu as écris, mais je n'ai pas l'impression que tu as lu ce que j'ai écris.
-- Gaby
Gabriel Dos Reis
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,
j'ai noté ce que tu as écrit, mais je n'ai pas l'impression que tu as lu ce que j'ai écrit.
-- Gaby
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,
j'ai noté ce que tu as écrit, mais je n'ai pas l'impression que tu as
lu ce que j'ai écrit.
| 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,
j'ai noté ce que tu as écrit, mais je n'ai pas l'impression que tu as lu ce que j'ai écrit.
-- Gaby
Hamiral
candide writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Faut pas exagérer non plus. Moi je dirais plutôt "de l'entraînement", parce que c'est vrai que les manpages sont rarement utilisables telles quelles par ceux qui n'en ont jamais (ou peu) utilisé.
-- Hamiral
candide <candide@domain.invalid> writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Faut pas exagérer non plus. Moi je dirais plutôt "de l'entraînement",
parce que c'est vrai que les manpages sont rarement utilisables telles
quelles par ceux qui n'en ont jamais (ou peu) utilisé.
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Faut pas exagérer non plus. Moi je dirais plutôt "de l'entraînement", parce que c'est vrai que les manpages sont rarement utilisables telles quelles par ceux qui n'en ont jamais (ou peu) utilisé.
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?
J'ai participé à l'écriture d'un debugger, printer le stack toussa, c'est de la programmation rébarbative, c'est plus chiant que la mort,,. Je ne vais pas dire que je n'en utilise jamais, j'ai utilisé gdb ce millénaire pas plus tard que l'année dernière, cela peut aider et ça m'a aidé mais je n'en fais pas un outil de test, c'est juste quand je suis dans la merde de chez merde, à cause d'un bug tellement évident qu'on ne le remarque pas. C'est de l'artillerie lourde, pas une solution pour tester.
-- http://harpo.free.fr/
Jean-Marc Bourguet wrote:
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?
J'ai participé à l'écriture d'un debugger, printer le stack toussa,
c'est de la programmation rébarbative, c'est plus chiant que la mort,,.
Je ne vais pas dire que je n'en utilise jamais, j'ai utilisé gdb ce
millénaire pas plus tard que l'année dernière, cela peut aider et ça
m'a aidé mais je n'en fais pas un outil de test, c'est juste quand je
suis dans la merde de chez merde, à cause d'un bug tellement évident
qu'on ne le remarque pas.
C'est de l'artillerie lourde, pas une solution pour tester.
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?
J'ai participé à l'écriture d'un debugger, printer le stack toussa, c'est de la programmation rébarbative, c'est plus chiant que la mort,,. Je ne vais pas dire que je n'en utilise jamais, j'ai utilisé gdb ce millénaire pas plus tard que l'année dernière, cela peut aider et ça m'a aidé mais je n'en fais pas un outil de test, c'est juste quand je suis dans la merde de chez merde, à cause d'un bug tellement évident qu'on ne le remarque pas. C'est de l'artillerie lourde, pas une solution pour tester.
-- http://harpo.free.fr/
Harpo
Gabriel Dos Reis wrote:
candide writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Un écran et un clavier peuvent aussi aider, je me demande parfois ce qui est le plus essentiel.
-- http://harpo.free.fr/
Gabriel Dos Reis wrote:
candide <candide@domain.invalid> writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Un écran et un clavier peuvent aussi aider, je me demande parfois ce qui
est le plus essentiel.
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Un écran et un clavier peuvent aussi aider, je me demande parfois ce qui est le plus essentiel.
-- http://harpo.free.fr/
Harpo
Hamiral wrote:
candide writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Faut pas exagérer non plus. Moi je dirais plutôt "de l'entraînement",
Entrainer les cervelles vides les remplieraient-elles ?
parce que c'est vrai que les manpages sont rarement utilisables telles quelles par ceux qui n'en ont jamais (ou peu) utilisé.
Les man pages sont très utiles dans certains domaines et ne valent rien dans d'autres. Quand elles documentent des fonctions comme strlen() ou strcpy(), elles sont très précises et concises. Je ne fais pas de strcpy tous les millénaires, s'il me venait à l'idée d'en faire un ce millénaire ci, je taperais 'man strcpy', s'il me venait à l'idée d'utiiser 'The gimp', il ne viendrais pa à l'idée de taper 'man gimp'. C'est une question de niveau de documentation.
-- http://harpo.free.fr/
Hamiral wrote:
candide <candide@domain.invalid> writes:
[...]
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Faut pas exagérer non plus. Moi je dirais plutôt "de l'entraînement",
Entrainer les cervelles vides les remplieraient-elles ?
parce que c'est vrai que les manpages sont rarement utilisables telles
quelles par ceux qui n'en ont jamais (ou peu) utilisé.
Les man pages sont très utiles dans certains domaines et ne valent rien
dans d'autres. Quand elles documentent des fonctions comme strlen() ou
strcpy(), elles sont très précises et concises. Je ne fais pas de
strcpy tous les millénaires, s'il me venait à l'idée d'en faire un ce
millénaire ci, je taperais 'man strcpy', s'il me venait à l'idée
d'utiiser 'The gimp', il ne viendrais pa à l'idée de taper 'man gimp'.
C'est une question de niveau de documentation.
| Question : Qu'est ce qu'il faut pour comprendre la doc ?
Réponse : une cervelle
Faut pas exagérer non plus. Moi je dirais plutôt "de l'entraînement",
Entrainer les cervelles vides les remplieraient-elles ?
parce que c'est vrai que les manpages sont rarement utilisables telles quelles par ceux qui n'en ont jamais (ou peu) utilisé.
Les man pages sont très utiles dans certains domaines et ne valent rien dans d'autres. Quand elles documentent des fonctions comme strlen() ou strcpy(), elles sont très précises et concises. Je ne fais pas de strcpy tous les millénaires, s'il me venait à l'idée d'en faire un ce millénaire ci, je taperais 'man strcpy', s'il me venait à l'idée d'utiiser 'The gimp', il ne viendrais pa à l'idée de taper 'man gimp'. C'est une question de niveau de documentation.
-- http://harpo.free.fr/
candide
Jean-Marc Bourguet wrote in news::
Apprendre a utiliser une debugger, c'est plutôt apprendre à en être dépendant.
C'est un point de vue.
Au fait, quel est l'aspect que tu trouves pédagogique dans l'utilisation d'un debugger?
Si on aime le judo, on comprend mieux ce qui se passe si on voit mouvements au ralenti, c'est pas plus compliqué que ça. Maintenant, je pense pas que David Douillet est devenu champion olympique assis devant son scope.
Le debugger, au peu de ce que j'ai découvert cette semaine, ça permet rendre le code _tangible_, il cesse d'être une abstraction, on fait des arrêts sur images, on les ralentit, on les accélère, on peut voir toutes les variables, on peut même les changer, remonter la pile des appels, tracer le code, voir les adresses consécutives d'un tableau (j'ai pas testé pour les structures), on est comme chez soi. Je crois que c'est avec le debugger hier que j'ai pris conscience qu'une fonction avait une adresse, pourtant les livres le disaient bien. En disant cela, je me rends compte qu'une partie de mes problèmes vient de ce que je ne sais pas fondamentalement ce qu'est du code exécutable, que je connais que très vaguement le fonctionnement de la mémoire. C'est pour ça que je répète qu'il ne faut pas commencer le C avec du "hello word". Bon, pour essayer de me cultiver, j'ai commandé le livre suivant :
/Memory as a Programming Concept in C and C++/ (Frantisek FRANEK) et que j'ai hâte de recevoir, je crois que ça va répondre à un tas de mes questions, si vous l'avez lu, dites-moi votre avis. J'espère que je ne le retournerai pas comme j'ai dû le faire pour le livre qu'Alain Deniau conseillait "C Interfaces and Implementations" arhh, beaucoup beaucoup trop dur (et intello, aucune méchanceté dans ce propos) pour l'instant.
Candide
Jean-Marc Bourguet <jm@bourguet.org> wrote in
news:87hd7ft3r9.fsf@news.bourguet.org:
Apprendre a utiliser une debugger, c'est plutôt apprendre à
en être dépendant.
C'est un point de vue.
Au fait, quel est l'aspect que tu trouves pédagogique dans
l'utilisation d'un debugger?
Si on aime le judo, on comprend mieux ce qui se passe si on voit
mouvements au ralenti, c'est pas plus compliqué que ça. Maintenant, je
pense pas que David Douillet est devenu champion olympique assis devant son
scope.
Le debugger, au peu de ce que j'ai découvert cette semaine, ça permet
rendre le code _tangible_, il cesse d'être une abstraction, on fait des
arrêts sur images, on les ralentit, on les accélère, on peut voir toutes
les variables, on peut même les changer, remonter la pile des appels,
tracer le code, voir les adresses consécutives d'un tableau (j'ai pas testé
pour les structures), on est comme chez soi. Je crois que c'est avec le
debugger hier que j'ai pris conscience qu'une fonction avait une adresse,
pourtant les livres le disaient bien. En disant cela, je me rends compte
qu'une partie de mes problèmes vient de ce que je ne sais pas
fondamentalement ce qu'est du code exécutable, que je connais que très
vaguement le fonctionnement de la mémoire. C'est pour ça que je répète
qu'il ne faut pas commencer le C avec du "hello word". Bon, pour essayer de
me cultiver, j'ai commandé le livre suivant :
/Memory as a Programming Concept in C and C++/ (Frantisek FRANEK) et que
j'ai hâte de recevoir, je crois que ça va répondre à un tas de mes
questions, si vous l'avez lu, dites-moi votre avis. J'espère que je ne le
retournerai pas comme j'ai dû le faire pour le livre qu'Alain Deniau
conseillait "C Interfaces and Implementations" arhh, beaucoup beaucoup trop
dur (et intello, aucune méchanceté dans ce propos) pour l'instant.
Apprendre a utiliser une debugger, c'est plutôt apprendre à en être dépendant.
C'est un point de vue.
Au fait, quel est l'aspect que tu trouves pédagogique dans l'utilisation d'un debugger?
Si on aime le judo, on comprend mieux ce qui se passe si on voit mouvements au ralenti, c'est pas plus compliqué que ça. Maintenant, je pense pas que David Douillet est devenu champion olympique assis devant son scope.
Le debugger, au peu de ce que j'ai découvert cette semaine, ça permet rendre le code _tangible_, il cesse d'être une abstraction, on fait des arrêts sur images, on les ralentit, on les accélère, on peut voir toutes les variables, on peut même les changer, remonter la pile des appels, tracer le code, voir les adresses consécutives d'un tableau (j'ai pas testé pour les structures), on est comme chez soi. Je crois que c'est avec le debugger hier que j'ai pris conscience qu'une fonction avait une adresse, pourtant les livres le disaient bien. En disant cela, je me rends compte qu'une partie de mes problèmes vient de ce que je ne sais pas fondamentalement ce qu'est du code exécutable, que je connais que très vaguement le fonctionnement de la mémoire. C'est pour ça que je répète qu'il ne faut pas commencer le C avec du "hello word". Bon, pour essayer de me cultiver, j'ai commandé le livre suivant :
/Memory as a Programming Concept in C and C++/ (Frantisek FRANEK) et que j'ai hâte de recevoir, je crois que ça va répondre à un tas de mes questions, si vous l'avez lu, dites-moi votre avis. J'espère que je ne le retournerai pas comme j'ai dû le faire pour le livre qu'Alain Deniau conseillait "C Interfaces and Implementations" arhh, beaucoup beaucoup trop dur (et intello, aucune méchanceté dans ce propos) pour l'instant.
