je crains fort d'être hors charte, mais bon tant pis pour moi, je pose
quand même ma question.
dans math.h, j'ai ceci :
#if defined __USE_BSD || defined __USE_XOPEN
...
# define M_PI 3.14159265358979323846 /* pi */
...
#endif
puis plus loin :
#ifdef __USE_GNU
...
# define M_PIl 3.1415926535897932384626433832795029L /* pi */
...
#endif
Et dans mon programme, j'ai besoin d'une constante PI, même sans grande
précision (donc M_PI suffirait, mais 3.14 serait un peu juste). Hors, que
j'utilise M_PI ou M_PIl, le compilateur me dit :
pqtorus.c:40: error:`M_PIl' undeclared (first use in this function)
J'ai bien sur #includé math.h.
Dois-je définir l'une ou l'autre des constantes __USE_BSD, __USE_XOPEN,
__USE_GNU ? Ça ne me paraîtrait pas très propre ... Ou bien s'agit-il
d'une option de compilation qui me manque ?
Pour info j'utilise -Wall -std=c99 avec gcc3.3.4 (sous Debian si ça peut
avoir une quelconque importance).
Merci d'avance pour toute aide qui me serait précieuse.
--
Florent "flure" C.
Décrypter l'@ pour répondre
Coders don't die, they just JMP without RET !
je crains fort d'être hors charte, mais bon tant pis pour moi, je pose quand même ma question.
Non je ne pense pas...
dans math.h, j'ai ceci :
#if defined __USE_BSD || defined __USE_XOPEN ... # define M_PI 3.14159265358979323846 /* pi */ ... #endif
puis plus loin : #ifdef __USE_GNU ... # define M_PIl 3.1415926535897932384626433832795029L /* pi */ ... #endif
pqtorus.c:40: error:`M_PIl' undeclared (first use in this function)
J'ai bien sur #includé math.h.
Dois-je définir l'une ou l'autre des constantes __USE_BSD, __USE_XOPEN, __USE_GNU ? Ça ne me paraîtrait pas très propre ... Ou bien s'agit-il d'une option de compilation qui me manque ? Pour info j'utilise -Wall -stdÉ9 avec gcc3.3.4 (sous Debian si ça peut avoir une quelconque importance).
il faut bien définir les constantes pour utiliser ces M_PI. C'est pas que ce n'est pas propre, c'est juste que la norme du C elle même ne définit pas de constante Pi. Il faut donc inclure des choses non standard pour y avoir accès. En fait, la norme du C ne donne donc pas de constante Pi, celle ci est calculable par contre avec la fonction arctangente de la librairie standard.
un truc du genre peut donc suffir :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Florent 'flure' C. wrote:
Bonjour,
Bonjour
je crains fort d'être hors charte, mais bon tant pis pour moi, je pose
quand même ma question.
Non je ne pense pas...
dans math.h, j'ai ceci :
#if defined __USE_BSD || defined __USE_XOPEN
...
# define M_PI 3.14159265358979323846 /* pi */
...
#endif
puis plus loin :
#ifdef __USE_GNU
...
# define M_PIl 3.1415926535897932384626433832795029L /* pi */
...
#endif
pqtorus.c:40: error:`M_PIl' undeclared (first use in this function)
J'ai bien sur #includé math.h.
Dois-je définir l'une ou l'autre des constantes __USE_BSD, __USE_XOPEN,
__USE_GNU ? Ça ne me paraîtrait pas très propre ... Ou bien s'agit-il
d'une option de compilation qui me manque ?
Pour info j'utilise -Wall -stdÉ9 avec gcc3.3.4 (sous Debian si ça peut
avoir une quelconque importance).
il faut bien définir les constantes pour utiliser ces M_PI. C'est pas que ce
n'est pas propre, c'est juste que la norme du C elle même ne définit pas de
constante Pi. Il faut donc inclure des choses non standard pour y avoir
accès. En fait, la norme du C ne donne donc pas de constante Pi, celle ci
est calculable par contre avec la fonction arctangente de la librairie
standard.
un truc du genre peut donc suffir :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou
non.
Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
je crains fort d'être hors charte, mais bon tant pis pour moi, je pose quand même ma question.
Non je ne pense pas...
dans math.h, j'ai ceci :
#if defined __USE_BSD || defined __USE_XOPEN ... # define M_PI 3.14159265358979323846 /* pi */ ... #endif
puis plus loin : #ifdef __USE_GNU ... # define M_PIl 3.1415926535897932384626433832795029L /* pi */ ... #endif
pqtorus.c:40: error:`M_PIl' undeclared (first use in this function)
J'ai bien sur #includé math.h.
Dois-je définir l'une ou l'autre des constantes __USE_BSD, __USE_XOPEN, __USE_GNU ? Ça ne me paraîtrait pas très propre ... Ou bien s'agit-il d'une option de compilation qui me manque ? Pour info j'utilise -Wall -stdÉ9 avec gcc3.3.4 (sous Debian si ça peut avoir une quelconque importance).
il faut bien définir les constantes pour utiliser ces M_PI. C'est pas que ce n'est pas propre, c'est juste que la norme du C elle même ne définit pas de constante Pi. Il faut donc inclure des choses non standard pour y avoir accès. En fait, la norme du C ne donne donc pas de constante Pi, celle ci est calculable par contre avec la fonction arctangente de la librairie standard.
un truc du genre peut donc suffir :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Florent 'flure' C.
Le Sat, 18 Sep 2004 14:43:47 +0200, Anthony Fleury a écrit :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Anthony
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ; probablement parce que j'utilisais C++ au lieu de C ?
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en haut de pqtorus.c, j'obtiens ceci :
pqtorus.c:6: error: un élément de l'initialisation n'est pas une constante
J'ai essayé en virant static, en virant const, et même en virant les deux ... rien n'y fait ...
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Le Sat, 18 Sep 2004 14:43:47 +0200, Anthony Fleury a écrit :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c
ou non.
Anthony
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ;
probablement parce que j'utilisais C++ au lieu de C ?
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en
haut de pqtorus.c, j'obtiens ceci :
pqtorus.c:6: error: un élément de l'initialisation n'est pas une
constante
J'ai essayé en virant static, en virant const, et même en virant les
deux ... rien n'y fait ...
--
Florent "flure" C.
Décrypter l'@ pour répondre
Coders don't die, they just JMP without RET !
Le Sat, 18 Sep 2004 14:43:47 +0200, Anthony Fleury a écrit :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Anthony
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ; probablement parce que j'utilisais C++ au lieu de C ?
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en haut de pqtorus.c, j'obtiens ceci :
pqtorus.c:6: error: un élément de l'initialisation n'est pas une constante
J'ai essayé en virant static, en virant const, et même en virant les deux ... rien n'y fait ...
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Jean-Marc
"Florent 'flure' C." a écrit dans le message de news:
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Anthony
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ; probablement parce que j'utilisais C++ au lieu de C ?
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en haut de pqtorus.c, j'obtiens ceci :
pqtorus.c:6: error: un élément de l'initialisation n'est pas une constante
Hello, c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec autre chose qu'une constante. (mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double monPI = 3.141592657;
-- Jean-marc
"Florent 'flure' C." <flurePASDESPAM@freePASDESPAM.fr> a écrit dans le
message de news:pan.2004.09.18.12.52.21.411574@freePASDESPAM.fr...
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c
ou non.
Anthony
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ;
probablement parce que j'utilisais C++ au lieu de C ?
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en
haut de pqtorus.c, j'obtiens ceci :
pqtorus.c:6: error: un élément de l'initialisation n'est pas une
constante
Hello,
c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec autre
chose qu'une constante.
(mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire:
static const double monPI = 3.141592657;
"Florent 'flure' C." a écrit dans le message de news:
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Anthony
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ; probablement parce que j'utilisais C++ au lieu de C ?
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en haut de pqtorus.c, j'obtiens ceci :
pqtorus.c:6: error: un élément de l'initialisation n'est pas une constante
Hello, c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec autre chose qu'une constante. (mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double monPI = 3.141592657;
-- Jean-marc
Anthony Fleury
Florent 'flure' C. wrote:
Le Sat, 18 Sep 2004 14:43:47 +0200, Anthony Fleury a écrit :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ; probablement parce que j'utilisais C++ au lieu de C ?
Non le C++ ne définit pas non plus cette constante (à ma connaissance). gcc possède la constante M_PI mais pas d'autres compilateurs (dans VC++ faut définir une macro comme dans le cas du C avec gcc)
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en haut de pqtorus.c, j'obtiens ceci : pqtorus.c:6: error: un élément de l'initialisation n'est pas une constante J'ai essayé en virant static, en virant const, et même en virant les deux ... rien n'y fait ...
Oops, c'est ma faute je dis une bêtise, désolé. En fait il y a trois solutions : définir cette constante dans une fonction si elle n'est utilisée que dans une seule fonction, ou passer par une macro : #define pi 4*atan(1.0) ou passer (si la précision est suffisante) par une initialisation à la main de la constante :
(static) const double pi = 3.14159265358979323844...
Faisant un peu trop de C++ en ce moment j'ai oublié que l'on ne pouvait pas définir de variables globales dépendant d'un appel de fonction ou autre en C.
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Florent 'flure' C. wrote:
Le Sat, 18 Sep 2004 14:43:47 +0200, Anthony Fleury a écrit :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c
ou non.
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ;
probablement parce que j'utilisais C++ au lieu de C ?
Non le C++ ne définit pas non plus cette constante (à ma connaissance). gcc
possède la constante M_PI mais pas d'autres compilateurs (dans VC++ faut
définir une macro comme dans le cas du C avec gcc)
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en
haut de pqtorus.c, j'obtiens ceci :
pqtorus.c:6: error: un élément de l'initialisation n'est pas une
constante
J'ai essayé en virant static, en virant const, et même en virant les
deux ... rien n'y fait ...
Oops, c'est ma faute je dis une bêtise, désolé. En fait il y a trois
solutions : définir cette constante dans une fonction si elle n'est
utilisée que dans une seule fonction, ou passer par une macro : #define pi
4*atan(1.0) ou passer (si la précision est suffisante) par une
initialisation à la main de la constante :
(static) const double pi = 3.14159265358979323844...
Faisant un peu trop de C++ en ce moment j'ai oublié que l'on ne pouvait pas
définir de variables globales dépendant d'un appel de fonction ou autre en
C.
Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
Le Sat, 18 Sep 2004 14:43:47 +0200, Anthony Fleury a écrit :
#include <math.h>
(static) const double pi = 4*atan(1.0);
static selon si la portée de la constante pi doit se limiter à pqtorus.c ou non.
Eh bien je tombe des nues, je n'avais jamais eu ce problème avant ; probablement parce que j'utilisais C++ au lieu de C ?
Non le C++ ne définit pas non plus cette constante (à ma connaissance). gcc possède la constante M_PI mais pas d'autres compilateurs (dans VC++ faut définir une macro comme dans le cas du C avec gcc)
toujours est-il que si je mets static const double pi = 4.0*atan(1.0); en haut de pqtorus.c, j'obtiens ceci : pqtorus.c:6: error: un élément de l'initialisation n'est pas une constante J'ai essayé en virant static, en virant const, et même en virant les deux ... rien n'y fait ...
Oops, c'est ma faute je dis une bêtise, désolé. En fait il y a trois solutions : définir cette constante dans une fonction si elle n'est utilisée que dans une seule fonction, ou passer par une macro : #define pi 4*atan(1.0) ou passer (si la précision est suffisante) par une initialisation à la main de la constante :
(static) const double pi = 3.14159265358979323844...
Faisant un peu trop de C++ en ce moment j'ai oublié que l'on ne pouvait pas définir de variables globales dépendant d'un appel de fonction ou autre en C.
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Florent 'flure' C.
Le Sat, 18 Sep 2004 15:18:38 +0200, Jean-Marc a écrit :
Hello, c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec autre chose qu'une constante. (mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double monPI = 3.141592657;
En fait, comme c'est une constante dont j'ai besoin dans la plupart des fichiers de mon (petit) projet, je voulais utiliser la constante de math.h comme il me semblait avoir toujours fait jusqu'à maintenant ... Je vais néanmoins opter pour cette option ... Par contre, est-ce une mauvaise idée d'appeler cette constante M_PI, comme dans math.h ?
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Le Sat, 18 Sep 2004 15:18:38 +0200, Jean-Marc a écrit :
Hello,
c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec
autre chose qu'une constante.
(mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double
monPI = 3.141592657;
En fait, comme c'est une constante dont j'ai besoin dans la plupart des
fichiers de mon (petit) projet, je voulais utiliser la constante de math.h
comme il me semblait avoir toujours fait jusqu'à maintenant ...
Je vais néanmoins opter pour cette option ...
Par contre, est-ce une mauvaise idée d'appeler cette constante M_PI,
comme dans math.h ?
--
Florent "flure" C.
Décrypter l'@ pour répondre
Coders don't die, they just JMP without RET !
Le Sat, 18 Sep 2004 15:18:38 +0200, Jean-Marc a écrit :
Hello, c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec autre chose qu'une constante. (mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double monPI = 3.141592657;
En fait, comme c'est une constante dont j'ai besoin dans la plupart des fichiers de mon (petit) projet, je voulais utiliser la constante de math.h comme il me semblait avoir toujours fait jusqu'à maintenant ... Je vais néanmoins opter pour cette option ... Par contre, est-ce une mauvaise idée d'appeler cette constante M_PI, comme dans math.h ?
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Jean-Marc
"Florent 'flure' C." a écrit dans le message de news:
Hello, c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec autre chose qu'une constante. (mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double monPI = 3.141592657;
En fait, comme c'est une constante dont j'ai besoin dans la plupart des fichiers de mon (petit) projet, je voulais utiliser la constante de math.h comme il me semblait avoir toujours fait jusqu'à maintenant ... Je vais néanmoins opter pour cette option ... Par contre, est-ce une mauvaise idée d'appeler cette constante M_PI, comme dans math.h ?
Oui je dirais que c'est une mauvaise idée, juste pour le jour ou ce source sera recompilé sur une machine ou par le jeu des #define, M_PI sera déja définie dans math.h.
Donc j'obterais pour une "constante privée", genre MY_VALUE_OF_PI ...
Au passage, et pour répondre à un post précédent, faire un #define M_PI 4 *atan(1.0) me semblait aussi une trèès mauvaise idée! pourquoi obliger le programme à recalculer PI à chaque fois ? PI me semble avoir une valeur bien constante, non ?
-- Jean-marc
-- Jean-marc
"Florent 'flure' C." <flurePASDESPAM@freePASDESPAM.fr> a écrit dans le
message de news:pan.2004.09.18.13.28.54.968707@freePASDESPAM.fr...
Hello,
c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec
autre chose qu'une constante.
(mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double
monPI = 3.141592657;
En fait, comme c'est une constante dont j'ai besoin dans la plupart des
fichiers de mon (petit) projet, je voulais utiliser la constante de math.h
comme il me semblait avoir toujours fait jusqu'à maintenant ...
Je vais néanmoins opter pour cette option ...
Par contre, est-ce une mauvaise idée d'appeler cette constante M_PI,
comme dans math.h ?
Oui je dirais que c'est une mauvaise idée, juste pour le jour ou ce source
sera recompilé sur une machine ou par le jeu des #define, M_PI sera déja
définie dans math.h.
Donc j'obterais pour une "constante privée", genre MY_VALUE_OF_PI ...
Au passage, et pour répondre à un post précédent, faire un
#define M_PI 4 *atan(1.0)
me semblait aussi une trèès mauvaise idée! pourquoi obliger le programme à
recalculer PI à chaque fois ? PI me semble avoir une valeur bien constante,
non ?
"Florent 'flure' C." a écrit dans le message de news:
Hello, c'est normal, ce n'est pas autorisé d'initialiser quelque chose avec autre chose qu'une constante. (mon compilateur me dit: 'initializer is not a constant'
pour quoi faire super compliqué, qd on peut faire: static const double monPI = 3.141592657;
En fait, comme c'est une constante dont j'ai besoin dans la plupart des fichiers de mon (petit) projet, je voulais utiliser la constante de math.h comme il me semblait avoir toujours fait jusqu'à maintenant ... Je vais néanmoins opter pour cette option ... Par contre, est-ce une mauvaise idée d'appeler cette constante M_PI, comme dans math.h ?
Oui je dirais que c'est une mauvaise idée, juste pour le jour ou ce source sera recompilé sur une machine ou par le jeu des #define, M_PI sera déja définie dans math.h.
Donc j'obterais pour une "constante privée", genre MY_VALUE_OF_PI ...
Au passage, et pour répondre à un post précédent, faire un #define M_PI 4 *atan(1.0) me semblait aussi une trèès mauvaise idée! pourquoi obliger le programme à recalculer PI à chaque fois ? PI me semble avoir une valeur bien constante, non ?
-- Jean-marc
-- Jean-marc
Arnaud Giersch
Samedi le 18 septembre 2004, vers 14:21:16 (CEST), Florent 'flure' C. a écrit:
pqtorus.c:40: error:`M_PIl' undeclared (first use in this function)
J'ai bien sur #includé math.h.
Dois-je définir l'une ou l'autre des constantes __USE_BSD, __USE_XOPEN, __USE_GNU ? Ça ne me paraîtrait pas très propre ... Ou bien s'agit- il d'une option de compilation qui me manque ?
C'un peu des deux. Il faut définir les macros qui vont bien. Voir le manuel :
info libc mathematics mathematical constants info libc feature test macros
Pour info j'utilise -Wall -stdÉ9 avec gcc3.3.4 (sous Debian si ça p eut avoir une quelconque importance).
C'est l'option "-stdÉ9" qui rend gcc plus strict par rapport à ce qui est défini.
-- Arnaud
Samedi le 18 septembre 2004, vers 14:21:16 (CEST), Florent 'flure'
C. a écrit:
pqtorus.c:40: error:`M_PIl' undeclared (first use in this function)
J'ai bien sur #includé math.h.
Dois-je définir l'une ou l'autre des constantes __USE_BSD, __USE_XOPEN,
__USE_GNU ? Ça ne me paraîtrait pas très propre ... Ou bien s'agit- il
d'une option de compilation qui me manque ?
C'un peu des deux. Il faut définir les macros qui vont bien. Voir le
manuel :
info libc mathematics mathematical constants
info libc feature test macros
Samedi le 18 septembre 2004, vers 14:21:16 (CEST), Florent 'flure' C. a écrit:
pqtorus.c:40: error:`M_PIl' undeclared (first use in this function)
J'ai bien sur #includé math.h.
Dois-je définir l'une ou l'autre des constantes __USE_BSD, __USE_XOPEN, __USE_GNU ? Ça ne me paraîtrait pas très propre ... Ou bien s'agit- il d'une option de compilation qui me manque ?
C'un peu des deux. Il faut définir les macros qui vont bien. Voir le manuel :
info libc mathematics mathematical constants info libc feature test macros
Pour info j'utilise -Wall -stdÉ9 avec gcc3.3.4 (sous Debian si ça p eut avoir une quelconque importance).
C'est l'option "-stdÉ9" qui rend gcc plus strict par rapport à ce qui est défini.
-- Arnaud
Anthony Fleury
Jean-Marc wrote:
Au passage, et pour répondre à un post précédent, faire un #define M_PI 4 *atan(1.0) me semblait aussi une trèès mauvaise idée! pourquoi obliger le programme à recalculer PI à chaque fois ? PI me semble avoir une valeur bien constante, non ?
C'est en effet la plus mauvaise méthode pour pallier au fait que l'ont ait pas le droit de définir des variables globales avec autre chose que des constantes littérales en C.
Cependant, si Pi est utilisé dans des gros calculs (donc propagation rapide de l'erreur) et un nombre raisonnable de fois, ca peut être une solution. Le mieux est quand même, si la constante est utilisée dans une fonction précise, de la définir en local, et là on ne la calcule qu'une fois. Enfin pour dire que le #define n'est peut être pas toujours suffisant, à moins de sortir faire du copier coller de bc ou de maple :-)
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Jean-Marc wrote:
Au passage, et pour répondre à un post précédent, faire un
#define M_PI 4 *atan(1.0)
me semblait aussi une trèès mauvaise idée! pourquoi obliger le programme à
recalculer PI à chaque fois ? PI me semble avoir une valeur bien
constante, non ?
C'est en effet la plus mauvaise méthode pour pallier au fait que l'ont ait
pas le droit de définir des variables globales avec autre chose que des
constantes littérales en C.
Cependant, si Pi est utilisé dans des gros calculs (donc propagation rapide
de l'erreur) et un nombre raisonnable de fois, ca peut être une solution.
Le mieux est quand même, si la constante est utilisée dans une fonction
précise, de la définir en local, et là on ne la calcule qu'une fois. Enfin
pour dire que le #define n'est peut être pas toujours suffisant, à moins de
sortir faire du copier coller de bc ou de maple :-)
Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
Au passage, et pour répondre à un post précédent, faire un #define M_PI 4 *atan(1.0) me semblait aussi une trèès mauvaise idée! pourquoi obliger le programme à recalculer PI à chaque fois ? PI me semble avoir une valeur bien constante, non ?
C'est en effet la plus mauvaise méthode pour pallier au fait que l'ont ait pas le droit de définir des variables globales avec autre chose que des constantes littérales en C.
Cependant, si Pi est utilisé dans des gros calculs (donc propagation rapide de l'erreur) et un nombre raisonnable de fois, ca peut être une solution. Le mieux est quand même, si la constante est utilisée dans une fonction précise, de la définir en local, et là on ne la calcule qu'une fois. Enfin pour dire que le #define n'est peut être pas toujours suffisant, à moins de sortir faire du copier coller de bc ou de maple :-)
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Richard Delorme
static const double monPI = 3.141592657;
TonPi a une drôle de valeur... C'est plutôt, en arrondissant : 3.141592654 Pour plus de précision : http://www.joyofpi.com/pi.html
-- Richard
static const double monPI = 3.141592657;
TonPi a une drôle de valeur...
C'est plutôt, en arrondissant : 3.141592654
Pour plus de précision :
http://www.joyofpi.com/pi.html
