Langage c

Résolu/Fermé
njl - 29 avril 2010 à 00:12
mamiemando Messages postés 33380 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 - 29 avril 2010 à 23:07
salut à tout
SVP j'ai un probléme dans ce code là et je n'arrive pas a le trouver aidez mois SVp et merci à l'avance
voici le code :

#include <stdio.h>
#include <stdlib.h>
#define pi=3.14
float s,r;
int main(int argc, char *argv[])
{
printf(" entrez le rayon\n");
scanf("%f",&r);
s=pi*r*r;
printf("la surface est:%.2f\n",s);


system("PAUSE");
return 0;
}
le compilateur me dit que la faute se trouve avant "=" et souligne la ligne : s=pi*r*r;
A voir également:

6 réponses

tksteph Messages postés 204 Date d'inscription samedi 20 mars 2010 Statut Membre Dernière intervention 3 janvier 2018 25
29 avril 2010 à 00:27
Enleve le = que tu met lorsque tu attribue la valeur 3.14 à pi, apres le #define .Utilise plustot #define pi 3.14 et tu ns dit ce que tu trouves.
Bon courag!
0
salut ton problème se trouve au niveau de la definition de pi sa serait plutot
#define pi 3.14
vla :)
0
mmerci bien pour votre aide c trés gentil ca marche
0
mamiemando Messages postés 33380 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 7 802
29 avril 2010 à 00:33
Ah ben oui c'est normal que ça plante. En C toutes les instructions commençant par # sont évaluées par le précompilateur. Le précompilateur ne sait rien faire d'autre que des opérations sur le texte.

Ainsi il faut écrire

#define PI 3.14


... pour que PI soit substitué par 3.14. Si tu écris "define PI = 3.14", PI sera substitué par "= 3.14" dans ton code.

De manière générale les constantes définies au travers d'un #define sont écrites en capitales. Afin d'avoir un code portable, on évite d'utiliser getchar("PAUSE"); qui n'a de sens que sous windows. On peut par exemple mettre à la place l'instruction :

getchar();


Cette instruction n'a d'intérêt que si tu lances ton programme depuis l'explorateur windows afin que la fenêtre de commande ms dos ne disparaisse pas immédiatement après l'exécution du programme. Cette considération vraiment n'a plus de sens si tu travailles par exemple sous linux ou sous macOS car tu lanceras ton programme directement dans un terminal.

D'un point de vue code c'est également une mauvaise habitude d'utiliser des variables globales (surtout quand c'est injustifié, comme ici avec s et r). Enfin, étant donné que ton programme ne manipules pas d'arguments quand il est lancé, ta fonction main n'a pas de raison d'utiliser argc et argv.

En toute rigueur il faudrait s'assurer que le rayon est positif.

Enfin, la constante pi est définie dans math.h et s'appelle M_PI. Ainsi le code pourrait ressembler plutôt à ceci :

#include <math.h>
#include <stdio.h>

int main(){
    double r, s;

    // Demander le rayon
    do{
        printf("r ? ");
        scanf("%lf",&r);
    }while(r < 0);

    // Calculer la surface
    s = r * r * M_PI;
    printf("s = %lf\n",s);

    // Fin du programme
    //getchar(); // à décommenter sous windows
    return 0;
}


Bonne chance
0
tksteph Messages postés 204 Date d'inscription samedi 20 mars 2010 Statut Membre Dernière intervention 3 janvier 2018 25
29 avril 2010 à 00:37
???
0
mamiemando Messages postés 33380 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 7 802
29 avril 2010 à 00:45
Quoi ??? :-)
0
tksteph Messages postés 204 Date d'inscription samedi 20 mars 2010 Statut Membre Dernière intervention 3 janvier 2018 25
29 avril 2010 à 00:55
Oh rien qui vaille la peine d'etre dit , oublie ça
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
pardon j'ai pas compris ce que tu veux dire peux tu être un peu claire
0
mamiemando Messages postés 33380 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 7 802
29 avril 2010 à 23:07
A) J'expliquais juste pourquoi ce que tu avais écrit ne compilait pas. Quand tu compiles un programme en C, il y a plusieurs étapes (et ce sont des notions importantes à appréhender pour comprendre les erreurs que ton IDE pourra afficher) :

1) la précompilation : toutes les directives précédées d'un # sont évaluées (et seules elles). Ca consiste essentiellement à "copier coller" des .h (#include) ou substituer des symboles (PI par exemple) par une chaîne de caractère.

En soit rien n'empêche d'écrire #define PI = 3.14, mais cela signifique que PI sera remplacé par "= PI". Ainsi écrire printf("%lf\n",PI); revient à écrire printf("%lf\n",=3.14); ce qui ne compilera pas.

2) la compilation : la syntaxe C du .c que l'on compile est vérifiée et doit être juste : les fonctions doivent être déclarées, la syntaxe doit être correcte etc... Si tout va bien le compilateur construit un binaire (.o). Sinon une erreur de compilation est levée.

Dans ton cas la substitution PI -> =3.14 déclenchait une erreur à ce moment là. Si la ligne qui fait planter la compilation à l'air juste mais fait intervenir des symboles évalués par le précompilateur (ce qui était ton cas), l'erreur vient sûrement des directives passées au précompilateur.

3) le linkage : tous les .o construits lors de l'étape 2 sont réunis en vue de construire le binaire final (un exécutable, une librairie, un module, ...). Lorsque les .o sont rassemblés. Chaque symbole (fonctions...) déclaré et manipulé doit être présent une et une seule fois, sinon une erreur de linkage est déclenchée.

B) Ensuite je t'ai proposé une version qui correspondrait plus à ce qu'on ferait :

- la constante pi est déjà définie dans libairie standard C et s'appelle M_PI. Elle est définie dans math.h

- dans un programme un utilisateur peut potentiellement faire n'importe quoi. Pour que ton programme soit robuste tu es sensé faire un minimum de vérification. Typiquement un rayon est une valeur positive.

- enfin l'instruction system("PAUSE"); n'a de sens que sous windows. Or un code source C devrait pouvoir compiler indépendamment du système (sous linux, macOS...). Ainsi on essaye autant que possible d'avoir un code universel.



tksteph > en fait on répondu en même temps hier :)
0