-ed- est un peu rigide donc il n'aime pas les flottants ;)
Sinon, ton exemple est pas mal bien qu'un peu surchargé et légèrement incomplet puisqu'il faudrait l'accompagner de l'affichage correspondant, chez moi :
Avec printf : 7 - 0.000000 , -0.000000 Avec printf : 12.500000 - 32.700000 , 7 Avec printf : 21474836487 - 12.500000 , 32.700000 Avec printf : 12.500000 - 32.700000 , 21474836487
avec les warnings suivants
$ gcc -W -Wall -stdÉ9 -pedantic -o x fclc.c fclc.c: Dans la fonction «main» : fclc.c:5: attention : format «%i» expects type «int», but argument 2 has type «long long int» fclc.c:6: attention : format «%i» expects type «int», but argument 4 has type «long long int»
Pierre Maurette a écrit :
-ed-, le 19/09/2009 a écrit :
On 19 sep, 09:41, "Florent GABRIEL" <florentgabr...@free.fr> wrote:
Un programme valant mieux que milles palabres :-)
/* -------- CODE ----------- */
#include <stdio.h>
#include <iostream.h>
Pas du C.
Ah. Je m'inqiétais sur votre santé. Me voilà rassuré.
Ne serait-il pas préférable de proposer au monsieur une manipulation sur
le thème:
-ed- est un peu rigide donc il n'aime pas les flottants ;)
Sinon, ton exemple est pas mal bien qu'un peu surchargé et légèrement incomplet
puisqu'il faudrait l'accompagner de l'affichage correspondant, chez moi :
Avec printf : 7 - 0.000000 , -0.000000
Avec printf : 12.500000 - 32.700000 , 7
Avec printf : 21474836487 - 12.500000 , 32.700000
Avec printf : 12.500000 - 32.700000 , 21474836487
avec les warnings suivants
$ gcc -W -Wall -stdÉ9 -pedantic -o x fclc.c
fclc.c: Dans la fonction «main» :
fclc.c:5: attention : format «%i» expects type «int», but argument 2 has type
«long long int»
fclc.c:6: attention : format «%i» expects type «int», but argument 4 has type
«long long int»
-ed- est un peu rigide donc il n'aime pas les flottants ;)
Sinon, ton exemple est pas mal bien qu'un peu surchargé et légèrement incomplet puisqu'il faudrait l'accompagner de l'affichage correspondant, chez moi :
Avec printf : 7 - 0.000000 , -0.000000 Avec printf : 12.500000 - 32.700000 , 7 Avec printf : 21474836487 - 12.500000 , 32.700000 Avec printf : 12.500000 - 32.700000 , 21474836487
avec les warnings suivants
$ gcc -W -Wall -stdÉ9 -pedantic -o x fclc.c fclc.c: Dans la fonction «main» : fclc.c:5: attention : format «%i» expects type «int», but argument 2 has type «long long int» fclc.c:6: attention : format «%i» expects type «int», but argument 4 has type «long long int»
Pierre Maurette
candide, le 19/09/2009 a écrit :
Pierre Maurette a écrit :
[...]
-ed- est un peu rigide donc il n'aime pas les flottants ;)
Sinon, ton exemple est pas mal bien qu'un peu surchargé et légèrement incomplet puisqu'il faudrait l'accompagner de l'affichage correspondant, chez moi :
Je vous emmerde. Vous êtes insupportable. Et je vous autorise éventuellemnt à me vouvoyer.
-- Pierre Maurette
candide, le 19/09/2009 a écrit :
Pierre Maurette a écrit :
[...]
-ed- est un peu rigide donc il n'aime pas les flottants ;)
Sinon, ton exemple est pas mal bien qu'un peu surchargé et légèrement
incomplet puisqu'il faudrait l'accompagner de l'affichage correspondant, chez
moi :
Je vous emmerde. Vous êtes insupportable. Et je vous autorise
éventuellemnt à me vouvoyer.
-ed- est un peu rigide donc il n'aime pas les flottants ;)
Sinon, ton exemple est pas mal bien qu'un peu surchargé et légèrement incomplet puisqu'il faudrait l'accompagner de l'affichage correspondant, chez moi :
Je vous emmerde. Vous êtes insupportable. Et je vous autorise éventuellemnt à me vouvoyer.
-- Pierre Maurette
Benoit Izac
Bonjour,
le 19/09/2009 à 22:13, candide a écrit dans le message <4ab53b7a$0$3584$ :
PS : Si tu pouvais réduire la longueur de tes lignes de manière à ce qu'elles fassent au maximum 76 caractères, ce serait plus facile de te lire et de te répondre. -- Benoit Izac
Bonjour,
le 20/09/2009 à 09:34, candide <candide@free.invalid> a écrit dans le
message <4ab5db0c$0$854$426a74cc@news.free.fr> :
Avec printf : 7 - 0.000000 , -0.000000
^^^^^^^^ ^^^^^^^^^
Avec printf : 12.500000 - 32.700000 , 7
Avec printf : 21474836487 - 12.500000 , 32.700000
Avec printf : 12.500000 - 32.700000 , 21474836487
Il y a un bug.
Je confirme qu'il s'agit de l'affichage obtenu chez moi avec gcc sous
Linux.
Sous Windows avec mingw, l'affichage est le suivant :
Avec printf : 7 - 0.000000 , -0.000000
Avec printf : 12.500000 - 32.700000 , 7
Avec printf : 7 - 0.000000 , -0.000000
Avec printf : 12.500000 - 32.700000 , 7
Process returned 0 (0x0) execution time : 0.078 s
Press any key to continue.
[Il me semble qu'il l'affichage des long long est bogué avec ce
compilateur pour une sombre histoire de compatibilité avec le runtime
de Microsoft].
Ce qui est étrange, c'est que tes « "%f", 12.5 » marche une fois sur
deux...
PS : Si tu pouvais réduire la longueur de tes lignes de manière à ce
qu'elles fassent au maximum 76 caractères, ce serait plus facile de te
lire et de te répondre.
--
Benoit Izac
PS : Si tu pouvais réduire la longueur de tes lignes de manière à ce qu'elles fassent au maximum 76 caractères, ce serait plus facile de te lire et de te répondre. -- Benoit Izac
Benoit Izac
Bonjour,
le 20/09/2009 à 11:09, candide a écrit dans le message <4ab5f13e$0$12978$ :
Ce qui est étrange, c'est que tes « "%f", 12.5 » marche une fois sur deux...
Avec un UB, il peut justement se passer n'importe quoi. Maintenant, je crois que nous attendons tous les explications de la personnes qui a posé ce problème et qui a voulu savamment voulu nous instruire.
Vu que j'interviens peu sur ce groupe mais que je le lis assidûment, j'en profite pour vous (toi, pm et ed) signaler que vos petits tiraillages systématiques sont fatiguants à lire. Tu n'y es pas étranger étant donné qu'à pratiquement chacune de leurs interventions, tu leur sautes dessus. C'est vraiment dommage car chacun de vous à quelque chose à apporter au groupe (avec son style qu'on aime ou qu'on aime pas).
PS : Si tu pouvais réduire la longueur de tes lignes de manière à ce qu'elles fassent au maximum 76 caractères, ce serait plus facile de te lire et de te répondre.
Volontiers. En fouillant dans les options de Thunderbird (*), il apparait que je suis réglé sur 80 caractères, je modifie donc en 76 mais je ne suis pas sûr que cela résolve le problème.
C'est parfait ; 72 serait encore mieux car ça permet de faire au moins deux réponses sans avoir à reformatter.
-- Benoit Izac
Bonjour,
le 20/09/2009 à 11:09, candide <candide@free.invalid> a écrit dans le
message <4ab5f13e$0$12978$426a74cc@news.free.fr> :
Ce qui est étrange, c'est que tes « "%f", 12.5 » marche une fois sur
deux...
Avec un UB, il peut justement se passer n'importe quoi. Maintenant, je
crois que nous attendons tous les explications de la personnes qui
a posé ce problème et qui a voulu savamment voulu nous instruire.
Vu que j'interviens peu sur ce groupe mais que je le lis assidûment,
j'en profite pour vous (toi, pm et ed) signaler que vos petits
tiraillages systématiques sont fatiguants à lire. Tu n'y es pas étranger
étant donné qu'à pratiquement chacune de leurs interventions, tu leur
sautes dessus. C'est vraiment dommage car chacun de vous à quelque chose
à apporter au groupe (avec son style qu'on aime ou qu'on aime pas).
PS : Si tu pouvais réduire la longueur de tes lignes de manière à ce
qu'elles fassent au maximum 76 caractères, ce serait plus facile de
te lire et de te répondre.
Volontiers. En fouillant dans les options de Thunderbird (*), il
apparait que je suis réglé sur 80 caractères, je modifie donc en 76
mais je ne suis pas sûr que cela résolve le problème.
C'est parfait ; 72 serait encore mieux car ça permet de faire au moins
deux réponses sans avoir à reformatter.
le 20/09/2009 à 11:09, candide a écrit dans le message <4ab5f13e$0$12978$ :
Ce qui est étrange, c'est que tes « "%f", 12.5 » marche une fois sur deux...
Avec un UB, il peut justement se passer n'importe quoi. Maintenant, je crois que nous attendons tous les explications de la personnes qui a posé ce problème et qui a voulu savamment voulu nous instruire.
Vu que j'interviens peu sur ce groupe mais que je le lis assidûment, j'en profite pour vous (toi, pm et ed) signaler que vos petits tiraillages systématiques sont fatiguants à lire. Tu n'y es pas étranger étant donné qu'à pratiquement chacune de leurs interventions, tu leur sautes dessus. C'est vraiment dommage car chacun de vous à quelque chose à apporter au groupe (avec son style qu'on aime ou qu'on aime pas).
PS : Si tu pouvais réduire la longueur de tes lignes de manière à ce qu'elles fassent au maximum 76 caractères, ce serait plus facile de te lire et de te répondre.
Volontiers. En fouillant dans les options de Thunderbird (*), il apparait que je suis réglé sur 80 caractères, je modifie donc en 76 mais je ne suis pas sûr que cela résolve le problème.
C'est parfait ; 72 serait encore mieux car ça permet de faire au moins deux réponses sans avoir à reformatter.
-- Benoit Izac
Pierre Maurette
Benoit Izac, le 20/09/2009 a écrit :
Bonjour,
le 20/09/2009 à 09:34, candide a écrit dans le message <4ab5db0c$0$854$ :
Avec printf : 7 - 0.000000 , -0.000000 ^^^^^^^^ ^^^^^^^^^ Avec printf : 12.500000 - 32.700000 , 7 Avec printf : 21474836487 - 12.500000 , 32.700000 Avec printf : 12.500000 - 32.700000 , 21474836487
Il y a un bug.
Je confirme qu'il s'agit de l'affichage obtenu chez moi avec gcc sous Linux.
Sous Windows avec mingw, l'affichage est le suivant :
Avec printf : 7 - 0.000000 , -0.000000 Avec printf : 12.500000 - 32.700000 , 7 Avec printf : 7 - 0.000000 , -0.000000 Avec printf : 12.500000 - 32.700000 , 7
Process returned 0 (0x0) execution time : 0.078 s Press any key to continue.
[Il me semble qu'il l'affichage des long long est bogué avec ce compilateur pour une sombre histoire de compatibilité avec le runtime de Microsoft].
Ce qui est étrange, c'est que tes « "%f", 12.5 » marche une fois sur deux...
C'est le long long qui fout éventuellement le bordel. Quand il est en dernière position, ce qui est avant n'est pas affecté. Quand il est en première position, le code du main() envoit à la suite (dans la pile par exemple) un long long puis un double (transformé depuis un float) puis un autre double. Le code du printf() lit soit la même chose avec %lli, et tout va bien, soit avec %i un int à l'adresse du long long soit sur ma machine (taille des types et boutisme donné) 0x00000007, morceau de 0x0000000500000007. Et il lit les double à la suite. Ceux-ci font 8 octets. On lit donc à une adresse décalée de 4 octets. Le fait que ça donnera "souvent" 0.0 s'explique par le format des flottants. Si l'entier est en dernière position, sa valeur en sera affectée, mais pas celle des données qui précèdent.
Tout ceci est courant mais totalement dépendant de la plateforme, format des données, boutisme, conventions d'appel. Donc la norme ne permet pas de prévoir ce comportement.
-- Pierre Maurette
Benoit Izac, le 20/09/2009 a écrit :
Bonjour,
le 20/09/2009 à 09:34, candide <candide@free.invalid> a écrit dans le
message <4ab5db0c$0$854$426a74cc@news.free.fr> :
Avec printf : 7 - 0.000000 , -0.000000 ^^^^^^^^
^^^^^^^^^ Avec printf : 12.500000 - 32.700000 , 7
Avec printf : 21474836487 - 12.500000 , 32.700000
Avec printf : 12.500000 - 32.700000 , 21474836487
Il y a un bug.
Je confirme qu'il s'agit de l'affichage obtenu chez moi avec gcc sous
Linux.
Sous Windows avec mingw, l'affichage est le suivant :
Avec printf : 7 - 0.000000 , -0.000000
Avec printf : 12.500000 - 32.700000 , 7
Avec printf : 7 - 0.000000 , -0.000000
Avec printf : 12.500000 - 32.700000 , 7
Process returned 0 (0x0) execution time : 0.078 s
Press any key to continue.
[Il me semble qu'il l'affichage des long long est bogué avec ce
compilateur pour une sombre histoire de compatibilité avec le runtime
de Microsoft].
Ce qui est étrange, c'est que tes « "%f", 12.5 » marche une fois sur
deux...
C'est le long long qui fout éventuellement le bordel. Quand il est en
dernière position, ce qui est avant n'est pas affecté. Quand il est en
première position, le code du main() envoit à la suite (dans la pile
par exemple) un long long puis un double (transformé depuis un float)
puis un autre double. Le code du printf() lit soit la même chose avec
%lli, et tout va bien, soit avec %i un int à l'adresse du long long
soit sur ma machine (taille des types et boutisme donné) 0x00000007,
morceau de 0x0000000500000007. Et il lit les double à la suite. Ceux-ci
font 8 octets. On lit donc à une adresse décalée de 4 octets. Le fait
que ça donnera "souvent" 0.0 s'explique par le format des flottants.
Si l'entier est en dernière position, sa valeur en sera affectée, mais
pas celle des données qui précèdent.
Tout ceci est courant mais totalement dépendant de la plateforme,
format des données, boutisme, conventions d'appel. Donc la norme ne
permet pas de prévoir ce comportement.
le 20/09/2009 à 09:34, candide a écrit dans le message <4ab5db0c$0$854$ :
Avec printf : 7 - 0.000000 , -0.000000 ^^^^^^^^ ^^^^^^^^^ Avec printf : 12.500000 - 32.700000 , 7 Avec printf : 21474836487 - 12.500000 , 32.700000 Avec printf : 12.500000 - 32.700000 , 21474836487
Il y a un bug.
Je confirme qu'il s'agit de l'affichage obtenu chez moi avec gcc sous Linux.
Sous Windows avec mingw, l'affichage est le suivant :
Avec printf : 7 - 0.000000 , -0.000000 Avec printf : 12.500000 - 32.700000 , 7 Avec printf : 7 - 0.000000 , -0.000000 Avec printf : 12.500000 - 32.700000 , 7
Process returned 0 (0x0) execution time : 0.078 s Press any key to continue.
[Il me semble qu'il l'affichage des long long est bogué avec ce compilateur pour une sombre histoire de compatibilité avec le runtime de Microsoft].
Ce qui est étrange, c'est que tes « "%f", 12.5 » marche une fois sur deux...
C'est le long long qui fout éventuellement le bordel. Quand il est en dernière position, ce qui est avant n'est pas affecté. Quand il est en première position, le code du main() envoit à la suite (dans la pile par exemple) un long long puis un double (transformé depuis un float) puis un autre double. Le code du printf() lit soit la même chose avec %lli, et tout va bien, soit avec %i un int à l'adresse du long long soit sur ma machine (taille des types et boutisme donné) 0x00000007, morceau de 0x0000000500000007. Et il lit les double à la suite. Ceux-ci font 8 octets. On lit donc à une adresse décalée de 4 octets. Le fait que ça donnera "souvent" 0.0 s'explique par le format des flottants. Si l'entier est en dernière position, sa valeur en sera affectée, mais pas celle des données qui précèdent.
Tout ceci est courant mais totalement dépendant de la plateforme, format des données, boutisme, conventions d'appel. Donc la norme ne permet pas de prévoir ce comportement.