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 !
A mon avis, #define M_PI 3.14etc aurait été plus intuitif et plus inspiré. En effet tu (ou un autre) pourrait en utilisant cette définition écrire un &M_PI quelque part sans remarquer l'erreur ; et ce n'est qu'un exemple.
Par ailleurs, plutot que le ifndef, moi j'aurais fait carrément :
A mon avis, #define M_PI 3.14etc aurait été plus intuitif et plus
inspiré. En effet tu (ou un autre) pourrait en utilisant cette
définition écrire un &M_PI quelque part sans remarquer l'erreur ; et ce
n'est qu'un exemple.
Par ailleurs, plutot que le ifndef, moi j'aurais fait carrément :
A mon avis, #define M_PI 3.14etc aurait été plus intuitif et plus inspiré. En effet tu (ou un autre) pourrait en utilisant cette définition écrire un &M_PI quelque part sans remarquer l'erreur ; et ce n'est qu'un exemple.
Par ailleurs, plutot que le ifndef, moi j'aurais fait carrément :
#undef M_PI #define M_PI etc...
Florent 'flure' C.
Le Sat, 18 Sep 2004 23:42:22 +0200, cedric a écrit :
A mon avis, #define M_PI 3.14etc aurait été plus intuitif et plus inspiré. En effet tu (ou un autre) pourrait en utilisant cette définition écrire un &M_PI quelque part sans remarquer l'erreur ; et ce n'est qu'un exemple.
Tout à fait, je m'en suis rapidement rendu compte : le compilo essayait d'instancier plusieurs fois const double M_PI ...
Par ailleurs, plutot que le ifndef, moi j'aurais fait carrément :
#undef M_PI #define M_PI etc...
ah par contre :
#ifndef M_PI #define M_PI .. #endif
a l'air de très bien fonctionner ...
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Le Sat, 18 Sep 2004 23:42:22 +0200, cedric a écrit :
A mon avis, #define M_PI 3.14etc aurait été plus intuitif et plus
inspiré. En effet tu (ou un autre) pourrait en utilisant cette
définition écrire un &M_PI quelque part sans remarquer l'erreur ; et ce
n'est qu'un exemple.
Tout à fait, je m'en suis rapidement rendu compte : le compilo essayait
d'instancier plusieurs fois const double M_PI ...
Par ailleurs, plutot que le ifndef, moi j'aurais fait carrément :
#undef M_PI
#define M_PI etc...
ah par contre :
#ifndef M_PI
#define M_PI ..
#endif
a l'air de très bien fonctionner ...
--
Florent "flure" C.
Décrypter l'@ pour répondre
Coders don't die, they just JMP without RET !
A mon avis, #define M_PI 3.14etc aurait été plus intuitif et plus inspiré. En effet tu (ou un autre) pourrait en utilisant cette définition écrire un &M_PI quelque part sans remarquer l'erreur ; et ce n'est qu'un exemple.
Tout à fait, je m'en suis rapidement rendu compte : le compilo essayait d'instancier plusieurs fois const double M_PI ...
Par ailleurs, plutot que le ifndef, moi j'aurais fait carrément :
#undef M_PI #define M_PI etc...
ah par contre :
#ifndef M_PI #define M_PI .. #endif
a l'air de très bien fonctionner ...
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
J'espère qu'il n'y a pas de contre-indications à cela ?
Définir un symbole dont il est connu (et même attendu) qu'il est communément utilisé comme macro à autre chose qu'une macro me semble de très mauvais style.
C'est pas beau, mais dans ce sens-là ce n'est pas vraiment un problème:
Si tu définis avant M_PI, la constante est court-circuitée: pas vraiment un souci. Si tu définis M_PI après, tu auras la macro, dont on suppose que la valeur est similaire. Si tu rajoute un #undef après, rien ne se passe.
Le seul souci, c'est s'il utilise M_PI avec &: cela marchera silencieusement en mode ISO, mais ne marchera plus en mode BSD ou GNU.
Autre chose un peu surprenante, c'est que si le .h est inclus plusieurs fois (problème quelconque avec la protection contre les inclusions multiples), on va obtenir une erreur de double définition.
Pour faire bon poids, j'aurais ajouté dans le #ifndef
#define M_PI M_PI
Mais c'est un potentiel générateur de problèmes (augmenter la complexité de manière non nécessaire n'est jamais une bonne chose; de plus on peut toujours tomber sur un préprocesseur antédiluvien qui va entrer en boucle sans fin).
Antoine
En 878yb7tt4k.fsf@news.bourguet.org, Jean-Marc Bourguet va escriure:
J'espère qu'il n'y a pas de contre-indications à cela ?
Définir un symbole dont il est connu (et même attendu) qu'il
est communément utilisé comme macro à autre chose qu'une
macro me semble de très mauvais style.
C'est pas beau, mais dans ce sens-là ce n'est pas vraiment un problème:
Si tu définis avant M_PI, la constante est court-circuitée: pas vraiment un
souci.
Si tu définis M_PI après, tu auras la macro, dont on suppose que la valeur
est similaire.
Si tu rajoute un #undef après, rien ne se passe.
Le seul souci, c'est s'il utilise M_PI avec &: cela marchera silencieusement
en mode ISO, mais ne marchera plus en mode BSD ou GNU.
Autre chose un peu surprenante, c'est que si le .h est inclus plusieurs fois
(problème quelconque avec la protection contre les inclusions multiples), on
va obtenir une erreur de double définition.
Pour faire bon poids, j'aurais ajouté dans le #ifndef
#define M_PI M_PI
Mais c'est un potentiel générateur de problèmes (augmenter la complexité de
manière non nécessaire n'est jamais une bonne chose; de plus on peut
toujours tomber sur un préprocesseur antédiluvien qui va entrer en boucle
sans fin).
J'espère qu'il n'y a pas de contre-indications à cela ?
Définir un symbole dont il est connu (et même attendu) qu'il est communément utilisé comme macro à autre chose qu'une macro me semble de très mauvais style.
C'est pas beau, mais dans ce sens-là ce n'est pas vraiment un problème:
Si tu définis avant M_PI, la constante est court-circuitée: pas vraiment un souci. Si tu définis M_PI après, tu auras la macro, dont on suppose que la valeur est similaire. Si tu rajoute un #undef après, rien ne se passe.
Le seul souci, c'est s'il utilise M_PI avec &: cela marchera silencieusement en mode ISO, mais ne marchera plus en mode BSD ou GNU.
Autre chose un peu surprenante, c'est que si le .h est inclus plusieurs fois (problème quelconque avec la protection contre les inclusions multiples), on va obtenir une erreur de double définition.
Pour faire bon poids, j'aurais ajouté dans le #ifndef
#define M_PI M_PI
Mais c'est un potentiel générateur de problèmes (augmenter la complexité de manière non nécessaire n'est jamais une bonne chose; de plus on peut toujours tomber sur un préprocesseur antédiluvien qui va entrer en boucle sans fin).
Antoine
James Kanze
Jean-Marc Bourguet writes:
|> "Florent 'flure' C." writes:
|> > En fait j'a choisi cette méthode finalement :
|> > J'espère qu'il n'y a pas de contre-indications à cela ?
|> Définir un symbole dont il est connu (et même attendu) qu'il est |> communément utilisé comme macro à autre chose qu'une macro me semble |> de très mauvais style.
C'est pire, si c'est du C. Parce qu'en C, un const n'est pas static par défaut. Il risque donc d'avoir des définitions multiples lors de l'édition des liens.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > J'espère qu'il n'y a pas de contre-indications à cela ?
|> Définir un symbole dont il est connu (et même attendu) qu'il est
|> communément utilisé comme macro à autre chose qu'une macro me semble
|> de très mauvais style.
C'est pire, si c'est du C. Parce qu'en C, un const n'est pas static par
défaut. Il risque donc d'avoir des définitions multiples lors de
l'édition des liens.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > J'espère qu'il n'y a pas de contre-indications à cela ?
|> Définir un symbole dont il est connu (et même attendu) qu'il est |> communément utilisé comme macro à autre chose qu'une macro me semble |> de très mauvais style.
C'est pire, si c'est du C. Parce qu'en C, un const n'est pas static par défaut. Il risque donc d'avoir des définitions multiples lors de l'édition des liens.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
