je suis vraiment un pur débutant et je voudrais savoir pourquoi mon programme ne se compile pas entierement  il s'arrete a  
1-  addition 2-soustraction 3-division 4-multiplication 5- modulo
voici mon programme
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[])
{
  long resultat = 0, nombre1 = 0, nombre2 = 0, choix = 0;
   
  printf("choississez les nombre" );
  scanf(" %d %d",&nombre1,&nombre2);
  printf("choississez l'operation a faire \n" );
  printf("1-  addition 2-soustraction 3-division 4-multiplication 5- modulo" );
  scanf("entrer votre choix %d",&choix);
                if(choix==1)
    {
    printf ("%ld + %ld = %ld\n", nombre1, nombre2, resultat);
    }
                 else if (choix==2)
    {
    printf ("%ld - %ld = %ld\n", nombre1, nombre2, resultat);
    }
 
                 else if (choix==3)
    {
    printf ("%ld / %ld = %ld\n", nombre1, nombre2, resultat);  
    }  
                 else if (choix==4)
    {
    printf ("%ld * %ld = %ld\n", nombre1, nombre2, resultat);  
    }  
                else if (choix==5)
    {
    printf ("%ld % %ld = %ld\n", nombre1, nombre2, resultat);  
    }  
  system("PAUSE" );  
  return 0;
}

heu tu fais un scanf alors il attend que tu lui donne une valeur
Au lieux de recopier bêtement du code commence par lire un tutorial sur le C

fais un printf ("entrez votre code\n" );
puis scanf("%d",&choix);

sebou je suis en train de lire un tuto sur le C mais j'ai du mal c'est pourquoi je demande de l'aide or si je recopirai je ne vous demanderai pas de l'aide maintenant je vous demande une autre aide (merci antho j'ai réparer mon erreur mm si ce n'était pas tout a fait sa (bien que ce que tu mai di etait vrai)) la je vous demande pourquoi dans mon code les resultat sont toujour = a 0  si j'enleve le resultat = 0 c'est faut et si je met tout simplement resultat sa me fais des calcule faut du genre 45+5=2
merci de l'aide que vous m'apporter ^^

je voulais aussi savoir c'est normal que le C soit vachement dur pour moi (eleve de 1ere S) le C c'est dur pour tout le monde je suis trop jeune ou c'est que je suis pas fait pour l'informatique ^^?

resultat fait toujours zéro car tu ne fais pas l'opération
il faut mettre resultat=nombre1+nombre2;
(par exemple pour l'addition)

Si t'arrive pas à comprendre ca intuitivement t'es ptêtre pas "né" pour l'informatique, mais ca exclut pas qu'en bossant tu arrive à de bonnes choses. Mais faudra bosser un peu...

normal que resultat soit toujours égal à 0 : tu ne remplis jamais sa valeur.
il faut mettre des instructions du genre "resultat = nombre1 + nombre2;" avant tes printf.
 
Par ailleurs
1) tu devrais gérer les cas où l'utilisateur rentre une opération qui n'existe pas
2) il existe en C une structure switch qui t'aiderait sans doute à faire quelque chose de plus propre et plus lisible  

 
 
 
EDIT: GRILLAID (et d'1/4 d'heure en plus...)

 
Le C te donne assez de corde pour te pendre.
Si tu étudies ça par plaisir, il n'y a aucune raison pour que tu n'y arrives pas.
Si tu parles anglais, un tuto sympa:
 
http://beej.us/guide/bgc/output/html/index.html
 
Sinon,
 
http://www-clips.imag.fr/commun/be [...] NSI_C.html
 
Mais c'est plus formel.
 

 
 
char c
 
Ne jamais utiliser de char ailleurs que dans une chaîne. C'est un coup à faire des conneries.

 
L'âge n'a rien à voir. Et, en général, les élèves de S sont "généralement" cablés pour savoir facilement transformer la solution d'un pb en algorithme informatique.
Si tu veux savoir si t'es fait pour l'informatique, est-ce que t'as une calculatrice progammable ? Est-ce que tu prends plaisir à la programmer ?
 
Sinon, est-ce que tu fais un blocage sue le C pur ? Trop tôt pour le dire. Quand tu réussiras tout seul à faire des programmes fonctionnels et que tu les verras tourner, c'est là que tu verras si t'es fait pour ça (si tu as envie de continuer, etc)
 
 

Pourquoi
 
Si tu fais gaffe, il n'y a aucune raison de faire des conneries...

 
Parce qu'aucune fonction ne prend ni ne renvoie de char.
On ne travaille pas avec des char: tu ne t'es pas demandé pourquoi les fonctions du style getchar() renvoient des int?

n'importe quoi, tu utilises char quand tu veux du moment que tu fais attention a la concordance des types.
c'est sur que faut pas faire char c = getchar() mais ca suffit de lire la doc (comme pour toute les fonctions), getchar renvoi EOF en cas d'erreur et le type de EOF est int
 
dans l'exemple de francesco je vois pas en quoi l'utilisation de char est dangereuse

 
Non.
Si les fonctions comme getchar retournent des int, c'est parce qu'ils doivent signaler une erreur possible, qui doit donc être distincte de toutes les valeurs de char possible. Donc si tu l'affectes à un char, tu te retrouves avec un overflow ou une troncature, et ça te donne de la merde.
 
En parlant de getchar, regarde le prototype de putchar: comme toutes ses soeurs, elle accepte un type int. Pourtant tu ne lui balances pas EOF là?
Les fonctions qui travaillent sur des caractères acceptent et renvoient des int, on travaille donc avec des int: elles les convertissent en unsigned char (et oui, le fait que char soit signed dépend de l'implémentation).
En plus, tu risques d'avoir plein de problèmes si tu les manipules (extension de signe, overflow, etc). Enfin, int est la taille d'un mot naturel de la machine (taille de ses registres), les calculs sont plus rapides, et demandent moins de boulot du compilateur.
 
Un dernier exemple: les constantes caractère sont de type int (essaie un sizeof('a') pour t'en convaincre).
 
Alors je ne vois vraiment aucune raison d'utiliser un char. A part pour se vautrer...

D'accord pour ce qui concerne l'alignement de la mémoire et la taille des registres : il est vrai qu'utiliser un int est plus efficace que d'utiliser un char.
 
Par contre, je vois toujours pas pourquoi on se vautrerait en utilisant des char. Mon exemple ne fait appel à aucune fonction du type getchar() / putchar(), ne fait aucune manipulation sur le caractère et je ne vois pas où il pourrait y avoir un risque de plantage.

 
Dans ton exemple, y'a rien à dire.
Mais c'est juste pour prendre de bonnes habitudes ;-)

 
c'est ce que j'ai dit
 

 
je sais et je vois pas ce que ca vient faire la
 

 
si on considere un char comme un caractere je vois pas le probleme, et l'overflow arithmetique concerne tout les types entiers.
 

 
je vois toujours pas ce que ca vient faire la, si on considere un char comme un caractere je vois mal comment on peut se retrouver a faire du calcul en masse sur des vecteurs de char ??
 

 
et alors ? expliques moi en quoi ce code serait faux
 
char c = 'a';
putchar(c);
 

 
C'est bien.  

 
Ah vraiment?
 

 
Et? T'as donc pas compris pourquoi il faut utiliser un int pour stocker la valeur de retour de getchar().
 

 
idem.
 

 
Ca te gènes pas d'affecter un int à un char (signed ou unsigned), pour qu'il soit passé à une fonction qui accepte un int, et qui le reconvertit en unsigned char?  
 
Après si ça t'amuses d'utiliser des chars pour recevoir/passer des valeurs à des fonctions qui reçoivent des ints, c'est ton problème.
Le fait est que les constantes caractère sont des int, et toutes les fonctions qui manipulent des caractères attendent/renvoient des int.
Alors je ne vois vraiment pas la logique qui peut pousser à utiliser des char.

 
je demandais juste de m'expliquer en quoi ce code peux poser des problemes, ce que tu n'as pas fais
 

 
je vois pas ou est le probleme de passer un char à une fonction prenant un int, surtout si il est convertit en 'unsigned char' derriere
pour le retour je n'ai jamais dit que je récupere dans un char un int, comme tu n'arrete pas de le repeter
 

 
ya rien a comprendre, getchar retourne un int, tu recuperes la valeur retour dans un int, apres si t'es heureux d'avoir compris que EOF converti en char peut etre confondu avec un autre char (sans blague) tant mieux pour toi
 

 
avoir un code plus cloisonner (donc plus robuste) et surtout plus proche de la sémantique (je l'ai dit 100x, un caractere est un caractere), mais cherches pas a comprendre, ca a pas l'air d'etre ce qui compte pour toi

En fait, la vraie raison, c'est que char n'est pas un type 'naturel'. Il n'y a pas de paramètres de type char. Il est automatiquement converti en int . Je confirme que char n'est utilise que pour les tableaux de char servant à faire des chaines.
 

Moi, je dis pas que c'est faux, mais que c'est moins efficace que :  

#define char int

Lisible et efficace

 
 
Bon, je n'ai envie ni de me fâcher avec toi, ni de perdre mon temps.
Je pense que c'est une mauvaise idée, et je ne crois pas être le seul (Emmanuel aussi apparemment). Après, chacun est libre de faire ce qu'il veut.
 
On arrête ici.

#define char int

 
Pfff...

 
Là, c'est tiptop !!!  

 
Sauf que ca marche pas

chrisbk avait raison : le C est une émanation de Satan !

 
Efficace en temps ? en espace ?
 
Je me permet une petite digression :
Ce problème est voisin de celui des calculs en float. Doit-on les utiliser sachant qu'il y a conversion en double ?
Je répond oui. Si on veut être efficace en espace -- voir dans certains cas en temps.
(sachant que ma réflexion n'inclu volontairement pas les problèmes de précision numérique).

En temps et en taille de code. Pas d'extension de signe, pas de troncature...

Ceci n'est pas un scoop :  

• Le calculs sont faits en double. Toujours.
• Le stockage de masse est fait en double, ou en float si on accepte la réduction de précision (au profit du volume d'information).

Tu pourrais clarifier, en ce qui concerne l'extension de signe et la troncature ?
 

Toujours ? Et en cas de vectorisation ?

Le type char n'est pas natif pour les calculs. Il est converti en int pour faire les calculs et reconvertit en char après le calcul.
 
char -> int : extension de signe : 0x82 -> 0xFF82
int -> char : troncature : 0xFF82 -> 0x80 : & 0xFF...
 

Toujours ? Et en cas de vectorisation ?
Vectorisation ? Pas de ça en C.

Merci.
 

Pas de vectorisation, mais un support direct pour la favoriser : restrict.
C'est au bon gré du compilateur selon le processeur ciblé. Et s'il y a un support harware pour effectuer des operations paralèlles sur des float, je serais étonné d'une conversion en double.  

C'est possible, car C99 a des fonctions de calcul en float et en long double...

 
tu veux dire que les operandes float sont toujours promues au moins en double (voir long double) ? mais les operations sur nombres reels au sein du cpu sont toujours faites avec le type reels le plus large (long double) ?

Je rephrase.
 
En C90, les calculs en internes sont faits avec la meilleure précision possible (double).
Les fonctions standard ont une interface de type double.
 
Il est donc souhaitable que les types des données soient 'double', ça évite des conversions inutiles et coûteuses
 
En C99, il existe des de fonctions de calculs spécialisées pour float et long double.

Emmanuel à déjà répondu :

 
à cause des fonctions standards C90, donc. Je ne sais pas ce qu'Emmanuel veux dire par "calculs en interne".
 

ça non, c'est le cas sur pentium, ou les flottants sont convertis sur 80 bits, mais ce n'est pas vrai en général.

(voir mon interrogation ci-dessus)
 

J'ai bien conscience d'être en contradiction avec la FAQ de fclc, mais si l'on ne fait pas appel aux fonctions standards C90 ?
Si on a l'intention de compiler ce code C avec un compilateur C++ pour profiter de la surcharge et éviter les conversions ?
Si on est dans le multimédia et qu'on veut profiter des instructions SIMD tel que SSE (éventuellement au lieu de SSE2) ?
Dans ces cas, ça me semble avoir un sens -- et ça ne me semble pas si rare, notament les 2 premiers points.
 

Qui ne sont plus compatible C++, c'est pénible

 
possible, je ne sais meme plus ou j'ai vu ca    
 

 
a quoi bon, le C n'est de toute facon pas compatible avec le C++, et t'u l'a dit, en C++ on as des surcharges

On peut dire ce qu'on veut, il y a quand même un sous ensemble C compatible C++ pas si restreint que ça.
Vu qu'on a des surcharges en C++, on peut parfois améliorer le binaire d'un code C en le compilant en C++, en évitant donc les conversions.
C99 introduit la solution du pauvre avec cosf et cie, et au mieux oblige le compilateur C++ à utiliser la compatibilité C99. Au pire à ce que ça ne soit pas compilable en C++.