Marc Espie a écrit :
mais bon, des annees d'explications de comment ca marche, des petites
cases memoire, et tout ca, conduisent a une vision etriquee de l'informatique
et du fonctionnement des machines.
Quand on programme, y compris en C, a-t-on nécessairement besoin de
connaître le fonctionnement des machines. Les variables sont des
abstractions.
Et entre devoir ecrire explicitement mes invariants de boucle et mes
conditions d'arret, ou avoir du recursif qui se prouve "naturellement" avec
une belle equation, le recursif c'est souvent plus simple.
Exemple ?
Marc Espie a écrit :
mais bon, des annees d'explications de comment ca marche, des petites
cases memoire, et tout ca, conduisent a une vision etriquee de l'informatique
et du fonctionnement des machines.
Quand on programme, y compris en C, a-t-on nécessairement besoin de
connaître le fonctionnement des machines. Les variables sont des
abstractions.
Et entre devoir ecrire explicitement mes invariants de boucle et mes
conditions d'arret, ou avoir du recursif qui se prouve "naturellement" avec
une belle equation, le recursif c'est souvent plus simple.
Exemple ?
Marc Espie a écrit :
mais bon, des annees d'explications de comment ca marche, des petites
cases memoire, et tout ca, conduisent a une vision etriquee de l'informatique
et du fonctionnement des machines.
Quand on programme, y compris en C, a-t-on nécessairement besoin de
connaître le fonctionnement des machines. Les variables sont des
abstractions.
Et entre devoir ecrire explicitement mes invariants de boucle et mes
conditions d'arret, ou avoir du recursif qui se prouve "naturellement" avec
une belle equation, le recursif c'est souvent plus simple.
Exemple ?
Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Cette phrase m'est resté et je la pense importante car elle montre que
l'informatique est un monde d'approximation (je veux dire par rapport à
la notion de "continu" en mathématique).
Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Cette phrase m'est resté et je la pense importante car elle montre que
l'informatique est un monde d'approximation (je veux dire par rapport à
la notion de "continu" en mathématique).
Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Cette phrase m'est resté et je la pense importante car elle montre que
l'informatique est un monde d'approximation (je veux dire par rapport à
la notion de "continu" en mathématique).
In article <4b1793c9$0$933$,
Wykaaa wrote:Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Marrant, quand je demande a Mathematica de me stocker racine de 2,
il me stocke racine de 2.
In article <4b1793c9$0$933$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Marrant, quand je demande a Mathematica de me stocker racine de 2,
il me stocke racine de 2.
In article <4b1793c9$0$933$,
Wykaaa wrote:Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Marrant, quand je demande a Mathematica de me stocker racine de 2,
il me stocke racine de 2.
Marc Boyer a écrit :Là, on parle d'attitudes, c'est pas vraiment du C.
C'est juste.Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas
génial comme attitude. Sortir la norme à ce moment là est
particulièrement hors-sujet à mon avis.
Le mieux étant bien entendu d'expliquer ce qu'elle
raconte plutôt que de recopier "in extenso" le paragraphe en anglais
sans le traduire (hierarchie fr.* pourtant).
Ca dépend de ce que t'entends par marcher.
Normalement si le code marche, personne ne postera ici pour s'en
plaindre.
Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher
Il y a très peu de gens qui croient encore qu'un code source ne doit
plus évoluer une fois écrit.
On raconte dans le métier qu'un prog sans bug est juste un prog mort
(ou non utilisé, c'est synonyme).
Marc Boyer a écrit :
Là, on parle d'attitudes, c'est pas vraiment du C.
C'est juste.
Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas
génial comme attitude. Sortir la norme à ce moment là est
particulièrement hors-sujet à mon avis.
Le mieux étant bien entendu d'expliquer ce qu'elle
raconte plutôt que de recopier "in extenso" le paragraphe en anglais
sans le traduire (hierarchie fr.* pourtant).
Ca dépend de ce que t'entends par marcher.
Normalement si le code marche, personne ne postera ici pour s'en
plaindre.
Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher
Il y a très peu de gens qui croient encore qu'un code source ne doit
plus évoluer une fois écrit.
On raconte dans le métier qu'un prog sans bug est juste un prog mort
(ou non utilisé, c'est synonyme).
Marc Boyer a écrit :Là, on parle d'attitudes, c'est pas vraiment du C.
C'est juste.Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas
génial comme attitude. Sortir la norme à ce moment là est
particulièrement hors-sujet à mon avis.
Le mieux étant bien entendu d'expliquer ce qu'elle
raconte plutôt que de recopier "in extenso" le paragraphe en anglais
sans le traduire (hierarchie fr.* pourtant).
Ca dépend de ce que t'entends par marcher.
Normalement si le code marche, personne ne postera ici pour s'en
plaindre.
Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher
Il y a très peu de gens qui croient encore qu'un code source ne doit
plus évoluer une fois écrit.
On raconte dans le métier qu'un prog sans bug est juste un prog mort
(ou non utilisé, c'est synonyme).
Marc Boyer a écrit :
Est-ce que direqu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.
int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}
Ca dépend de ce que t'entends par marcher. Normalement si le code
marche, personne ne postera ici pour s'en plaindre.
Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher (même si ca marche parce
que le prologue de la fonction a utilisé un registre qui vaut 0 et qui
est réutilisé plus tard pour la variable lsum). De toute façon je
recommande toujours une passe dans un lint/splint et autres qa-c quand
le code semble marcher[*]. Ensuite on corrige jusqu'a ce qu'il n'y ait
plus de warnings ni de grognement de gcc/lint/splint/qac.. A ce moment
là le code ne fait plus ce qui était prévu (il est correct, mais faux
car ne rempli plus le CdC), on re-corrige, on rejoue les tests, en cycle
et a un moment ca se stabilise et on est heureux: le travail est fini,
on peut sortir le produit et faire la recette :)
C'est chiant, mais c'est la vie. A ce niveau là, avoir choisi
un découpage de son logiciel de sorte à faciliter les portages, aide
beaucoup à la maintenance plus tard.
Marc Boyer a écrit :
Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.
int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}
Ca dépend de ce que t'entends par marcher. Normalement si le code
marche, personne ne postera ici pour s'en plaindre.
Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher (même si ca marche parce
que le prologue de la fonction a utilisé un registre qui vaut 0 et qui
est réutilisé plus tard pour la variable lsum). De toute façon je
recommande toujours une passe dans un lint/splint et autres qa-c quand
le code semble marcher[*]. Ensuite on corrige jusqu'a ce qu'il n'y ait
plus de warnings ni de grognement de gcc/lint/splint/qac.. A ce moment
là le code ne fait plus ce qui était prévu (il est correct, mais faux
car ne rempli plus le CdC), on re-corrige, on rejoue les tests, en cycle
et a un moment ca se stabilise et on est heureux: le travail est fini,
on peut sortir le produit et faire la recette :)
C'est chiant, mais c'est la vie. A ce niveau là, avoir choisi
un découpage de son logiciel de sorte à faciliter les portages, aide
beaucoup à la maintenance plus tard.
Marc Boyer a écrit :
Est-ce que direqu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.
int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}
Ca dépend de ce que t'entends par marcher. Normalement si le code
marche, personne ne postera ici pour s'en plaindre.
Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher (même si ca marche parce
que le prologue de la fonction a utilisé un registre qui vaut 0 et qui
est réutilisé plus tard pour la variable lsum). De toute façon je
recommande toujours une passe dans un lint/splint et autres qa-c quand
le code semble marcher[*]. Ensuite on corrige jusqu'a ce qu'il n'y ait
plus de warnings ni de grognement de gcc/lint/splint/qac.. A ce moment
là le code ne fait plus ce qui était prévu (il est correct, mais faux
car ne rempli plus le CdC), on re-corrige, on rejoue les tests, en cycle
et a un moment ca se stabilise et on est heureux: le travail est fini,
on peut sortir le produit et faire la recette :)
C'est chiant, mais c'est la vie. A ce niveau là, avoir choisi
un découpage de son logiciel de sorte à faciliter les portages, aide
beaucoup à la maintenance plus tard.
Marc Espie a écrit :In article <4b1793c9$0$933$,
Wykaaa wrote:Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Marrant, quand je demande a Mathematica de me stocker racine de 2,
il me stocke racine de 2.
C'était juste une façon de dire qu'un ordinateur n'a pas une mémoire
infinie.
Donc que racine de 2 est forcément tronqué ou alors c'est
l'algorithme qui est stocké et avec la patience nécessaire (et un algo
sophistiqué) tu vas pouvoir le recalculer jusqu'à, mettons, la
milliardième décimale :-)
Marc Espie a écrit :
In article <4b1793c9$0$933$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Marrant, quand je demande a Mathematica de me stocker racine de 2,
il me stocke racine de 2.
C'était juste une façon de dire qu'un ordinateur n'a pas une mémoire
infinie.
Donc que racine de 2 est forcément tronqué ou alors c'est
l'algorithme qui est stocké et avec la patience nécessaire (et un algo
sophistiqué) tu vas pouvoir le recalculer jusqu'à, mettons, la
milliardième décimale :-)
Marc Espie a écrit :In article <4b1793c9$0$933$,
Wykaaa wrote:Dès le premier cours d'informatique (c'était au début des années 70), on
m'a dit à peu près ceci : vous pouvez demander quasiment tout à un
ordinateur sauf de stocker racine de 2.
Marrant, quand je demande a Mathematica de me stocker racine de 2,
il me stocke racine de 2.
C'était juste une façon de dire qu'un ordinateur n'a pas une mémoire
infinie.
Donc que racine de 2 est forcément tronqué ou alors c'est
l'algorithme qui est stocké et avec la patience nécessaire (et un algo
sophistiqué) tu vas pouvoir le recalculer jusqu'à, mettons, la
milliardième décimale :-)
Normalement si le code marche, personne ne postera ici pour s'en
plaindre.
Pourtant un grnad nombre de fils commencent par « mon code ci-dessous
marche sur XYZ, et bogue quand duchmol essaye sur ABC ». Marchent ou
marchent pas ?
Normalement si le code marche, personne ne postera ici pour s'en
plaindre.
Pourtant un grnad nombre de fils commencent par « mon code ci-dessous
marche sur XYZ, et bogue quand duchmol essaye sur ABC ». Marchent ou
marchent pas ?
Normalement si le code marche, personne ne postera ici pour s'en
plaindre.
Pourtant un grnad nombre de fils commencent par « mon code ci-dessous
marche sur XYZ, et bogue quand duchmol essaye sur ABC ». Marchent ou
marchent pas ?
Marc Boyer a écrit :Là, on parle d'attitudes, c'est pas vraiment du C.
C'est juste.
Est-ce que direqu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas génial
comme attitude. Sortir la norme à ce moment là est particulièrement
hors-sujet à mon avis.
Marc Boyer a écrit :
Là, on parle d'attitudes, c'est pas vraiment du C.
C'est juste.
Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas génial
comme attitude. Sortir la norme à ce moment là est particulièrement
hors-sujet à mon avis.
Marc Boyer a écrit :Là, on parle d'attitudes, c'est pas vraiment du C.
C'est juste.
Est-ce que direqu'on programme ne respecte pas la norme c'est décourager les gens ?
En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.
Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.
L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas génial
comme attitude. Sortir la norme à ce moment là est particulièrement
hors-sujet à mon avis.
Lucas Levrel a crit :
> Le 1 d cembre 2009, candide a crit :
>>> #include <stdio.h>
>>> int main(void){
>>> int i;
>>> printf(" %i n", i ) ;
>>> return 0;
>>> }
>> M me si tu donnes a pour l'exemple, ce code est interdit :
> Quelqu'un a-t-il pr tendu le contraire ?
Non mais un code qui contient un UB ne peut rien prouver.
Lucas Levrel a crit :
> Le 1 d cembre 2009, candide a crit :
>>> #include <stdio.h>
>>> int main(void){
>>> int i;
>>> printf(" %i n", i ) ;
>>> return 0;
>>> }
>> M me si tu donnes a pour l'exemple, ce code est interdit :
> Quelqu'un a-t-il pr tendu le contraire ?
Non mais un code qui contient un UB ne peut rien prouver.
Lucas Levrel a crit :
> Le 1 d cembre 2009, candide a crit :
>>> #include <stdio.h>
>>> int main(void){
>>> int i;
>>> printf(" %i n", i ) ;
>>> return 0;
>>> }
>> M me si tu donnes a pour l'exemple, ce code est interdit :
> Quelqu'un a-t-il pr tendu le contraire ?
Non mais un code qui contient un UB ne peut rien prouver.
Et si tu m'/nous expliquais plut t pourquoi il est tellement scandaleux
d'initialiser par d faut z ro les variables automatiques ?
Tu as raison, la programmation en C au sens du travail d'un programmeur
ne m'int resse pas plus que a, pour l'instant en tous cas. Ce qui
Et si tu m'/nous expliquais plut t pourquoi il est tellement scandaleux
d'initialiser par d faut z ro les variables automatiques ?
Tu as raison, la programmation en C au sens du travail d'un programmeur
ne m'int resse pas plus que a, pour l'instant en tous cas. Ce qui
Et si tu m'/nous expliquais plut t pourquoi il est tellement scandaleux
d'initialiser par d faut z ro les variables automatiques ?
Tu as raison, la programmation en C au sens du travail d'un programmeur
ne m'int resse pas plus que a, pour l'instant en tous cas. Ce qui