Bonjour,
j'aimerais assigner '+inf' =E0 une variable, et je me demandais
comment faire ca de mani=E8re =E9l=E9gante en C/C++, qui ne g=E9n=E9rerait
aucun warning, ni a la compilation, ni =E0 l'=E9xecution.
J'ai essay=E9 :
const double inf =3D std::pow(1024.0,1024.0);
mais c'est pas tr=E8s beau. De plus, ca g=E9n=E8re un warning =E0
l'=E9xecution,
avec bcc32.
Est-ce que quelqu'un a une id=E9e ?
j'aimerais assigner '+inf' à une variable, et je me demandais comment faire ca de manière élégante en C/C++, qui ne générerait aucun warning, ni a la compilation, ni à l'éxecution.
En C ou en C++ ? car la réponse n'est pas la même... Enfin du moins ma réponse C++ ne fonctionnera pas en C. Mais comme on est sur un groupe C++, je considère C++ seulement.
j'aimerais assigner '+inf' à une variable, et je me demandais
comment faire ca de manière élégante en C/C++, qui ne générerait
aucun warning, ni a la compilation, ni à l'éxecution.
En C ou en C++ ? car la réponse n'est pas la même... Enfin du moins ma
réponse C++ ne fonctionnera pas en C. Mais comme on est sur un groupe
C++, je considère C++ seulement.
j'aimerais assigner '+inf' à une variable, et je me demandais comment faire ca de manière élégante en C/C++, qui ne générerait aucun warning, ni a la compilation, ni à l'éxecution.
En C ou en C++ ? car la réponse n'est pas la même... Enfin du moins ma réponse C++ ne fonctionnera pas en C. Mais comme on est sur un groupe C++, je considère C++ seulement.
j'aimerais assigner '+inf' à une variable, et je me demandais comment faire ca de manière élégante en C/C++, qui ne générerait aucun warning, ni a la compilation, ni à l'éxecution.
En C/C++, je ne sais pas, je ne connais pas ce langage.
J'avoue que je connais mal les flottants, mais si ça ne marche pas, je ne vois pas bien ce qui pourrait fonctionner.
On 28 May 2005 03:39:05 -0700, tournevissette@yahoo.fr:
j'aimerais assigner '+inf' à une variable, et je me demandais
comment faire ca de manière élégante en C/C++, qui ne générerait
aucun warning, ni a la compilation, ni à l'éxecution.
En C/C++, je ne sais pas, je ne connais pas ce langage.
j'aimerais assigner '+inf' à une variable, et je me demandais comment faire ca de manière élégante en C/C++, qui ne générerait aucun warning, ni a la compilation, ni à l'éxecution.
En C/C++, je ne sais pas, je ne connais pas ce langage.
À noter que sur mon Borland C++ 5.02 (que tu es trop jeune pour avoir connu),
Ah merci, moi qui déprimais à l'approche de mon prochain anniversaire me disant que mon âge approchait trop de std::numeric_limits<jeunesse>::max(); ca fait plaisir à lire :-)
Hum, erreur de souvenir de ma part, c'est en effet std::numeric_limits<float>::has_infinity qui est à true d'après la norme. Pour un double ca peut donc être à false. Et si j'ai bien tout compris, avec has_infinity == false, le comportement est indéfini. [puisqu'il est seulement dit que la valeur n'a de sens que si has_infinity != false]
-- Anthony Fleury
On Sat, 28 May 2005 13:33:12 +0200, Anthony Fleury
<fleury_anthony@hotmail.com_>:
À noter que sur mon Borland C++ 5.02 (que tu es trop jeune pour avoir
connu),
Ah merci, moi qui déprimais à l'approche de mon prochain anniversaire me
disant que mon âge approchait trop de
std::numeric_limits<jeunesse>::max(); ca fait plaisir à lire :-)
Hum, erreur de souvenir de ma part, c'est en effet
std::numeric_limits<float>::has_infinity qui est à true d'après la
norme. Pour un double ca peut donc être à false. Et si j'ai bien tout
compris, avec has_infinity == false, le comportement est indéfini.
[puisqu'il est seulement dit que la valeur n'a de sens que si
has_infinity != false]
À noter que sur mon Borland C++ 5.02 (que tu es trop jeune pour avoir connu),
Ah merci, moi qui déprimais à l'approche de mon prochain anniversaire me disant que mon âge approchait trop de std::numeric_limits<jeunesse>::max(); ca fait plaisir à lire :-)
Hum, erreur de souvenir de ma part, c'est en effet std::numeric_limits<float>::has_infinity qui est à true d'après la norme. Pour un double ca peut donc être à false. Et si j'ai bien tout compris, avec has_infinity == false, le comportement est indéfini. [puisqu'il est seulement dit que la valeur n'a de sens que si has_infinity != false]
-- Anthony Fleury
Anthony Fleury
On Sat, 28 May 2005 13:33:12 +0200, Anthony Fleury :
À noter que sur mon Borland C++ 5.02 (que tu es trop jeune pour avoir connu),
Ah merci, moi qui déprimais à l'approche de mon prochain anniversaire me disant que mon âge approchait trop de std::numeric_limits<jeunesse>::max(); ca fait plaisir à lire :-)
Hum, erreur de souvenir de ma part, c'est en effet std::numeric_limits<float>::has_infinity qui est à true d'après la norme. Pour un double ca peut donc être à false. Et si j'ai bien tout compris, avec has_infinity == false, le comportement est indéfini. [puisqu'il est seulement dit que la valeur n'a de sens que si has_infinity != false]. Pour ma part je me serai attendu à ce que cela renvoie std::numeric_limits<>::max();
-- Anthony Fleury
On Sat, 28 May 2005 13:33:12 +0200, Anthony Fleury
<fleury_anthony@hotmail.com_>:
À noter que sur mon Borland C++ 5.02 (que tu es trop jeune pour avoir
connu),
Ah merci, moi qui déprimais à l'approche de mon prochain anniversaire me
disant que mon âge approchait trop de
std::numeric_limits<jeunesse>::max(); ca fait plaisir à lire :-)
Hum, erreur de souvenir de ma part, c'est en effet
std::numeric_limits<float>::has_infinity qui est à true d'après la
norme. Pour un double ca peut donc être à false. Et si j'ai bien tout
compris, avec has_infinity == false, le comportement est indéfini.
[puisqu'il est seulement dit que la valeur n'a de sens que si
has_infinity != false]. Pour ma part je me serai attendu à ce que cela
renvoie std::numeric_limits<>::max();
À noter que sur mon Borland C++ 5.02 (que tu es trop jeune pour avoir connu),
Ah merci, moi qui déprimais à l'approche de mon prochain anniversaire me disant que mon âge approchait trop de std::numeric_limits<jeunesse>::max(); ca fait plaisir à lire :-)
Hum, erreur de souvenir de ma part, c'est en effet std::numeric_limits<float>::has_infinity qui est à true d'après la norme. Pour un double ca peut donc être à false. Et si j'ai bien tout compris, avec has_infinity == false, le comportement est indéfini. [puisqu'il est seulement dit que la valeur n'a de sens que si has_infinity != false]. Pour ma part je me serai attendu à ce que cela renvoie std::numeric_limits<>::max();
-- Anthony Fleury
Tournevissette
Merci, effectivement en fait je cherche plutot une syntaxe de type C. Mais bon, je sais comment en faire en C++ du coup, c'est pas plus mal :)
Merci, effectivement en fait je cherche plutot une syntaxe de type C.
Mais bon, je sais comment en faire en C++ du coup, c'est pas plus mal
:)
C'est bien ce que j'ai fait, mais ca m'interesse aussi d'avoir les deux approches.
Mais dans ce cas, il ne faut pas demander une approche de type C sur fr.comp.lang.c++, ni une approche de type C++ sur fr.comp.lang.basic...
Tournevissette
Mais dans ce cas, il ne faut pas demander une approche de type C sur fr.comp.lang.c++, ni une approche de type C++ sur fr.comp.lang.basic...
J'aime la réponse constructive...
Si on regarde un peu plus loin, pourquoi la représentation d'un nombre flottant infini devrait être dépendante du langage C ou C++, alors que les deux langages proposent à-priori les mêmes opérations de base pour le calcul sur les flottants ? A mon sens, représenter la notion d'infini en C ou C++ ne devrait pas être dépendante de quelconques includes spécifiques C ou C++. A priori, je peux obtenir un nombre inifi avec le même code valide en C/C++ :
float x; for (x=2; x<2*x; x*=2); std::fprintf(stderr,"x = %gn",x);
(Les "puristes" du C++ peuvent remplacer fprintf par le cout qui va bien ). Cet exemple me renvoit bien +Inf avec gcc ET g++.
Donc je me serais attendu à avoir une réponse indépendante de la différence entre C et C++, même si on peut faire ca de manière dépendante bien entendu, comme vous l'avez fait remarqué ici. Et bien entendu, le groupe fr.comp.lang.c_c++ n'existe pas....
A méditer, non ?
Mais dans ce cas, il ne faut pas demander une approche de type C sur
fr.comp.lang.c++, ni une approche de type C++ sur
fr.comp.lang.basic...
J'aime la réponse constructive...
Si on regarde un peu plus loin, pourquoi la représentation d'un nombre
flottant infini devrait être dépendante du langage C ou C++, alors
que les deux langages proposent à-priori les mêmes opérations de
base pour le calcul sur les flottants ?
A mon sens, représenter la notion d'infini en C ou C++ ne devrait pas
être dépendante de quelconques includes spécifiques C ou C++. A
priori, je peux obtenir un nombre inifi avec le même code valide en
C/C++ :
float x;
for (x=2; x<2*x; x*=2);
std::fprintf(stderr,"x = %gn",x);
(Les "puristes" du C++ peuvent remplacer fprintf par le cout qui va
bien ).
Cet exemple me renvoit bien +Inf avec gcc ET g++.
Donc je me serais attendu à avoir une réponse indépendante de la
différence entre C et C++, même si on peut faire ca de manière
dépendante bien entendu, comme vous l'avez fait remarqué ici. Et bien
entendu, le groupe fr.comp.lang.c_c++ n'existe pas....
Mais dans ce cas, il ne faut pas demander une approche de type C sur fr.comp.lang.c++, ni une approche de type C++ sur fr.comp.lang.basic...
J'aime la réponse constructive...
Si on regarde un peu plus loin, pourquoi la représentation d'un nombre flottant infini devrait être dépendante du langage C ou C++, alors que les deux langages proposent à-priori les mêmes opérations de base pour le calcul sur les flottants ? A mon sens, représenter la notion d'infini en C ou C++ ne devrait pas être dépendante de quelconques includes spécifiques C ou C++. A priori, je peux obtenir un nombre inifi avec le même code valide en C/C++ :
float x; for (x=2; x<2*x; x*=2); std::fprintf(stderr,"x = %gn",x);
(Les "puristes" du C++ peuvent remplacer fprintf par le cout qui va bien ). Cet exemple me renvoit bien +Inf avec gcc ET g++.
Donc je me serais attendu à avoir une réponse indépendante de la différence entre C et C++, même si on peut faire ca de manière dépendante bien entendu, comme vous l'avez fait remarqué ici. Et bien entendu, le groupe fr.comp.lang.c_c++ n'existe pas....
