Petite question de debutant en programmation:
comment faut-il si prendre pour apprendre la programmation en c/c++
Doit on prendre des cours, acheter des livres, refaire des programmes des
autres.......
Et vous, combient de temps avez vous mis pour devenir un "bon" programmateur
et comment vous vous y ete pris.
Il n'a pas intérêt. J'ai souvent les boucles for vides dans mon code.
Un bon compilateur ne met pas d'avertissement pour les boucles « vides » qui font quelque chose (dans le for lui-même j'imagine), mais il en met pour les boucles vides qui ne font rien, comme celle ci-haut. Tu en mets beaucoup dans tes programmes ?
Non, mais je n'ai jamais vu un compilateur qui en faisait la distinction, non plus.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Michel Michaud wrote:
Dans le message
1109698742.938276.90730@g14g2000cwa.googlegroups.com,
julien wrote:
for(int i=0; i<10; ++i);
a[i] = x;
Un bon compilo te met un warning...
Il n'a pas intérêt. J'ai souvent les boucles for vides dans
mon code.
Un bon compilateur ne met pas d'avertissement pour les boucles
« vides » qui font quelque chose (dans le for lui-même
j'imagine), mais il en met pour les boucles vides qui ne font
rien, comme celle ci-haut. Tu en mets beaucoup dans tes
programmes ?
Non, mais je n'ai jamais vu un compilateur qui en faisait la
distinction, non plus.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Il n'a pas intérêt. J'ai souvent les boucles for vides dans mon code.
Un bon compilateur ne met pas d'avertissement pour les boucles « vides » qui font quelque chose (dans le for lui-même j'imagine), mais il en met pour les boucles vides qui ne font rien, comme celle ci-haut. Tu en mets beaucoup dans tes programmes ?
Non, mais je n'ai jamais vu un compilateur qui en faisait la distinction, non plus.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
marc.boyer.news
julien wrote:
del yahoo wrote:
Quand à la programmation, dire qu'aucune règle n'admet d'exception, c'est en C++ assez ridicule aussi. Des règles en C++ avec des exceptions, on peut en faire plein, genre: - "on peut lancer une exception partout, sauf dans un destructeur" - "n'utilisez jamais de variable globale, mais des singletons, sauf quand vous ne pouvez pas faire autrement" - "ne mélanger jamais les types signées et non signés, réservez les types signés à l'arithmétique et les non signés aux champs de bits, sauf pour les tailles (size_t)" - "toujours utiliser l'héritage public pour traduire 'isA'", mais Gabriel fait hériter Vecteur2D de Point dans un de ces codes
C'est des régles pas des exceptions. Une exception n'a pas de raison logique. Après si tu me trouve une raison logique qui explique pourquoi certains mots finissant par "ou" prenent un x au puriel, et d'autre non, je te souhaite bon courage.
Trouve moi alors une explication logique au fait que tous les types entiers sont par défaut signés sauf char.
Passons au C (C++ ayant corrigé certaines abominations)
Et pourquoi void* est un type mais pas void ? Et pouquoi la sémantique de void change-t-elle suivant le contexte .
void* foo(void); void bar(void);
Et pourquoi quand on écrit la définition d'une fonction doit-on répéter exactement la signature de sa déclaration (si elle existe) mais pas pour les fonctions sans arguments ?
Et d'aileur les exceptions que tu sites, viennent d'une mauvaise conception de départ, mais au lieu de tout refaire, c'est plus simple de mettre une rustine.
Pareil pour les langues naturelles ?
Marc Boyer
julien <forum@no--Spam_the-last-dream.com> wrote:
marc.boyer@enseeiht.yahoo.fr.invalid del yahoo wrote:
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
c'est en C++ assez ridicule aussi. Des règles en C++ avec des
exceptions, on peut en faire plein, genre:
- "on peut lancer une exception partout, sauf dans un destructeur"
- "n'utilisez jamais de variable globale, mais des singletons, sauf
quand vous ne pouvez pas faire autrement"
- "ne mélanger jamais les types signées et non signés, réservez les
types signés à l'arithmétique et les non signés aux champs de bits,
sauf pour les tailles (size_t)"
- "toujours utiliser l'héritage public pour traduire 'isA'", mais
Gabriel fait hériter Vecteur2D de Point dans un de ces codes
C'est des régles pas des exceptions. Une exception n'a pas de raison
logique. Après si tu me trouve une raison logique qui explique pourquoi
certains mots finissant par "ou" prenent un x au puriel, et d'autre non,
je te souhaite bon courage.
Trouve moi alors une explication logique au fait que tous les types
entiers sont par défaut signés sauf char.
Passons au C (C++ ayant corrigé certaines abominations)
Et pourquoi void* est un type mais pas void ? Et pouquoi la sémantique de
void change-t-elle suivant le contexte .
void* foo(void);
void bar(void);
Et pourquoi quand on écrit la définition d'une fonction doit-on répéter
exactement la signature de sa déclaration (si elle existe) mais pas
pour les fonctions sans arguments ?
Et d'aileur les exceptions que tu sites, viennent d'une mauvaise
conception de départ, mais au lieu de tout refaire, c'est plus simple de
mettre une rustine.
Quand à la programmation, dire qu'aucune règle n'admet d'exception, c'est en C++ assez ridicule aussi. Des règles en C++ avec des exceptions, on peut en faire plein, genre: - "on peut lancer une exception partout, sauf dans un destructeur" - "n'utilisez jamais de variable globale, mais des singletons, sauf quand vous ne pouvez pas faire autrement" - "ne mélanger jamais les types signées et non signés, réservez les types signés à l'arithmétique et les non signés aux champs de bits, sauf pour les tailles (size_t)" - "toujours utiliser l'héritage public pour traduire 'isA'", mais Gabriel fait hériter Vecteur2D de Point dans un de ces codes
C'est des régles pas des exceptions. Une exception n'a pas de raison logique. Après si tu me trouve une raison logique qui explique pourquoi certains mots finissant par "ou" prenent un x au puriel, et d'autre non, je te souhaite bon courage.
Trouve moi alors une explication logique au fait que tous les types entiers sont par défaut signés sauf char.
Passons au C (C++ ayant corrigé certaines abominations)
Et pourquoi void* est un type mais pas void ? Et pouquoi la sémantique de void change-t-elle suivant le contexte .
void* foo(void); void bar(void);
Et pourquoi quand on écrit la définition d'une fonction doit-on répéter exactement la signature de sa déclaration (si elle existe) mais pas pour les fonctions sans arguments ?
Et d'aileur les exceptions que tu sites, viennent d'une mauvaise conception de départ, mais au lieu de tout refaire, c'est plus simple de mettre une rustine.
Pareil pour les langues naturelles ?
Marc Boyer
Michel Michaud
Dans le message ,
On Tue, 1 Mar 2005 15:38:04 -0500, "Michel Michaud" :
mais il en met pour les boucles vides qui ne font rien, comme celle ci-haut.
Donc, en gros,
for (int i=x; i!=y; ++i);
génère un warning, tandis que
for (Machin i=x; i!=y; ++i);
n'en génère pas ?
Entre autres...
Mais finalement, je n'ai aucune idée où j'ai vu ça, car mes compilateurs actuels ne donnent aucun avertissement, même à la boucle complètement vide. Je ne sais si j'ai vu ça sur un vieux compilateur C ou C++, sur Unix, etc., ou s'il faut une configuration particulière... :-(
Alors je retire tout ce que j'ai dit, jusqu'à preuve du contraire. (Et j'attends que Julien, qui a le premier parlé de l'avertissement sur une boucle vide, donne ses sources, ça pourra m'aider à retrouver la mémoire !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 6pl9219vd8bgqmp75kufte4vd9nhlh4ulh@4ax.com,
On Tue, 1 Mar 2005 15:38:04 -0500, "Michel Michaud" <mm@gdzid.com>:
mais il en met pour les boucles vides qui ne font rien, comme celle
ci-haut.
Donc, en gros,
for (int i=x; i!=y; ++i);
génère un warning, tandis que
for (Machin i=x; i!=y; ++i);
n'en génère pas ?
Entre autres...
Mais finalement, je n'ai aucune idée où j'ai vu ça, car mes
compilateurs actuels ne donnent aucun avertissement, même à
la boucle complètement vide. Je ne sais si j'ai vu ça sur un
vieux compilateur C ou C++, sur Unix, etc., ou s'il faut une
configuration particulière... :-(
Alors je retire tout ce que j'ai dit, jusqu'à preuve du
contraire. (Et j'attends que Julien, qui a le premier parlé
de l'avertissement sur une boucle vide, donne ses sources,
ça pourra m'aider à retrouver la mémoire !)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
On Tue, 1 Mar 2005 15:38:04 -0500, "Michel Michaud" :
mais il en met pour les boucles vides qui ne font rien, comme celle ci-haut.
Donc, en gros,
for (int i=x; i!=y; ++i);
génère un warning, tandis que
for (Machin i=x; i!=y; ++i);
n'en génère pas ?
Entre autres...
Mais finalement, je n'ai aucune idée où j'ai vu ça, car mes compilateurs actuels ne donnent aucun avertissement, même à la boucle complètement vide. Je ne sais si j'ai vu ça sur un vieux compilateur C ou C++, sur Unix, etc., ou s'il faut une configuration particulière... :-(
Alors je retire tout ce que j'ai dit, jusqu'à preuve du contraire. (Et j'attends que Julien, qui a le premier parlé de l'avertissement sur une boucle vide, donne ses sources, ça pourra m'aider à retrouver la mémoire !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Alain Naigeon
" del yahoo" a écrit dans le message news:
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement 1 union 2 qui en est une.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"marc.boyer@enseeiht.yahoo.fr.invalid del yahoo" <marc.boyer.news@free.fr> a
écrit dans le message news:
792a8d3f.0503010026.7907ef58@posting.google.com...
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement
1 union 2 qui en est une.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"julien" a écrit dans le message news: 42245d21$0$30327$
Comme je te l'ai fait remarqué,
Oooh, non !
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
dans un domaine qu'on ne l'ai pas dans un autre.
marc.boyer.news
"Alain Naigeon" wrote in message news:<42266ab1$0$31671$...
" del yahoo" a écrit dans le message news:
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement 1 union 2 qui en est une.
Donc, en language naturel, il n'existe pas d'exception non plus.
Marc
"Alain Naigeon" <anaigeon@free.fr> wrote in message news:<42266ab1$0$31671$636a15ce@news.free.fr>...
"marc.boyer@enseeiht.yahoo.fr.invalid del yahoo" <marc.boyer.news@free.fr> a
écrit dans le message news:
792a8d3f.0503010026.7907ef58@posting.google.com...
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement
1 union 2 qui en est une.
Donc, en language naturel, il n'existe pas d'exception non plus.
"Alain Naigeon" wrote in message news:<42266ab1$0$31671$...
" del yahoo" a écrit dans le message news:
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement 1 union 2 qui en est une.
Donc, en language naturel, il n'existe pas d'exception non plus.
Marc
Alain Naigeon
" del yahoo" a écrit dans le message news:
"Alain Naigeon" wrote in message news:<42266ab1$0$31671$...
" del yahoo" a
écrit dans le message news:
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement 1 union 2 qui en est une.
Donc, en language naturel, il n'existe pas d'exception non plus.
Ben si, faute de quoi n'importe quelle extrapolation aventureuse serait tenue pour vraie. Ou encore : une conjecture n'est pas un théorème. J'ajoute que dans un espace non dénombrable (production d'un langage) la preuve par induction (=constatation dénombrement des exceptions potentielles) me paraît inaccessible !
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"marc.boyer@enseeiht.yahoo.fr.invalid del yahoo" <marc.boyer.news@free.fr> a
écrit dans le message news:
792a8d3f.0503030312.3a1917f4@posting.google.com...
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:<42266ab1$0$31671$636a15ce@news.free.fr>...
"marc.boyer@enseeiht.yahoo.fr.invalid del yahoo"
<marc.boyer.news@free.fr> a
écrit dans le message news:
792a8d3f.0503010026.7907ef58@posting.google.com...
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement
1 union 2 qui en est une.
Donc, en language naturel, il n'existe pas d'exception non plus.
Ben si, faute de quoi n'importe quelle extrapolation
aventureuse serait tenue pour vraie. Ou encore :
une conjecture n'est pas un théorème. J'ajoute que
dans un espace non dénombrable (production d'un
langage) la preuve par induction (=constatation dénombrement des exceptions potentielles) me paraît
inaccessible !
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"Alain Naigeon" wrote in message news:<42266ab1$0$31671$...
" del yahoo" a
écrit dans le message news:
Quand à la programmation, dire qu'aucune règle n'admet d'exception,
Pour moi c'est la définition d'une règle.
1
- "on peut lancer une exception partout, sauf
donc c'est faux
2
sauf dans un destructeur"
le 1 n'est pas une "règle", c'est seulement 1 union 2 qui en est une.
Donc, en language naturel, il n'existe pas d'exception non plus.
Ben si, faute de quoi n'importe quelle extrapolation aventureuse serait tenue pour vraie. Ou encore : une conjecture n'est pas un théorème. J'ajoute que dans un espace non dénombrable (production d'un langage) la preuve par induction (=constatation dénombrement des exceptions potentielles) me paraît inaccessible !
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
espie
In article <422359d3$0$31675$, Alain Naigeon wrote:
"julien" a écrit dans le message news: 42235751$0$16914$
Ose me dire que tu n'a jamais fait de faute de frappe en programmant!
Bien sûr, mais alors on corrige dans un cas (bien forcé !), et dans l'autre cas on dit qu'on s'en fout -> donc ça veut dire qu'un compilateur mérite plus de respect qu'un humain ?! ("on s'en fout" s'applique à ceux dont les envois sont truffés de fautes en permanence, ou qui font 10 fautes en 3 lignes)
Desole de re-debarquer apres la bagarre, mais il y a un effet beaucoup plus vicieux.
Si on programme comme un goret et qu'on laisse le compilateur corriger les fautes... alors on ne corrige QUE les fautes que le compilateur repere !
et on corrige ensuite les fautes qui font planter le programme.
Et on corrige ensuite les fautes que le plan de tests repere.
Et apres on est surpris quand le client ne revient pas nous voir pour acheter la version suivante.
Bref, ca prend au final plus de temps (beaucoup) et ca donne un processus qui construit des programmes de tres nettement moins bonne qualite.
Pourquoi ne pas prendre les bonnes habitudes des le debut ?
In article <422359d3$0$31675$636a15ce@news.free.fr>,
Alain Naigeon <anaigeon@free.fr> wrote:
"julien" <forum@no--Spam_the-last-dream.com> a écrit dans le message news:
42235751$0$16914$636a15ce@news.free.fr...
Ose me dire que tu n'a jamais fait de faute de frappe en programmant!
Bien sûr, mais alors on corrige dans un cas (bien forcé !), et
dans l'autre cas on dit qu'on s'en fout -> donc ça veut dire
qu'un compilateur mérite plus de respect qu'un humain ?!
("on s'en fout" s'applique à ceux dont les envois sont truffés
de fautes en permanence, ou qui font 10 fautes en 3 lignes)
Desole de re-debarquer apres la bagarre, mais il y a un effet beaucoup
plus vicieux.
Si on programme comme un goret et qu'on laisse le compilateur corriger
les fautes... alors on ne corrige QUE les fautes que le compilateur
repere !
et on corrige ensuite les fautes qui font planter le programme.
Et on corrige ensuite les fautes que le plan de tests repere.
Et apres on est surpris quand le client ne revient pas nous voir pour
acheter la version suivante.
Bref, ca prend au final plus de temps (beaucoup) et ca donne un processus
qui construit des programmes de tres nettement moins bonne qualite.
Pourquoi ne pas prendre les bonnes habitudes des le debut ?
In article <422359d3$0$31675$, Alain Naigeon wrote:
"julien" a écrit dans le message news: 42235751$0$16914$
Ose me dire que tu n'a jamais fait de faute de frappe en programmant!
Bien sûr, mais alors on corrige dans un cas (bien forcé !), et dans l'autre cas on dit qu'on s'en fout -> donc ça veut dire qu'un compilateur mérite plus de respect qu'un humain ?! ("on s'en fout" s'applique à ceux dont les envois sont truffés de fautes en permanence, ou qui font 10 fautes en 3 lignes)
Desole de re-debarquer apres la bagarre, mais il y a un effet beaucoup plus vicieux.
Si on programme comme un goret et qu'on laisse le compilateur corriger les fautes... alors on ne corrige QUE les fautes que le compilateur repere !
et on corrige ensuite les fautes qui font planter le programme.
Et on corrige ensuite les fautes que le plan de tests repere.
Et apres on est surpris quand le client ne revient pas nous voir pour acheter la version suivante.
Bref, ca prend au final plus de temps (beaucoup) et ca donne un processus qui construit des programmes de tres nettement moins bonne qualite.
Pourquoi ne pas prendre les bonnes habitudes des le debut ?
Fabien LE LEZ
On Thu, 31 Mar 2005 11:01:50 +0000 (UTC), (Marc Espie):
Et apres on est surpris quand le client ne revient pas nous voir pour acheter la version suivante.
Je ne saurais trop encourager mes concurrents à utiliser ce genre de méthodes...
-- ;-)
On Thu, 31 Mar 2005 11:01:50 +0000 (UTC), espie@tetto.home (Marc
Espie):
Et apres on est surpris quand le client ne revient pas nous voir pour
acheter la version suivante.
Je ne saurais trop encourager mes concurrents à utiliser ce genre de
méthodes...
