Bonjour,
Je viens de commencer la programmation en C à la fac et je me sens un peu perdue... J'ai eu un exo à faire et je ne m'en sors pas. Pourtant il n'a pas l'air si dur. Donc si quelqu'un pouvait m'aider et me donner des conseils, je lui en serai très reconnaissante.
Voici l'énnoncé:
 
Ecrire un programme qui :  
 
saisit (en utilisant scanf)  un texte, ligne par ligne,  
remplace dans la ligne chaque lettre par la lettre qui la suit dans l'alphabet (a suit z).  
et chaque chiffre par le chiffre qui le précéde (9 précéde 0).  
puis l'affiche (en utilisant printf) en faisant précéder chaque ligne par son numéro suivi de 2 points ( et d'un espace.  
On supposera que le nombre maximal des lignes de textes à traiter est de 10, et que le nombre maximal de caractères par ligne est de 80. La fin de ligne est indiquée par \n et la fin de texte par un point (.).  
Indication:  
Une macro qui permet CHIFFRE(X) qui renvoie vrai si X est un CHIFFRE  
Une macro LETTRE_MAJ(X) qui renvoie vrai si X est une lettre majuscule  
Une macro LETTRE_MIN(X) qui renvoie vrai si X est une lettre minuscule  
Une macro LETTRE(X) qui renvoie vrai si X est une lettre  
Une macro SUIVANT(X,INF,SUP) qui donne le suivant de X, si  INF<=X<=SUP  
Une macro PRECEDENT(X,INF,SUP) qui donne le precedent de X, si  INF<=X<=SUP  
Une macro LIRE_LIGNE(X) qui lit une ligne (par scanf) et la stocke sous forme de chaine dans X
 
Merci    

Puisque l'exercice nécessite d'utiliser printf, je me sens obligé de répondre
 
Il y a une toute petite chose à savoir pour remplacer chaque lettre par celle qui la suit dans l'alphabet, à savoir que les caractères ne sont rien d'autre que des nombres entiers consécutifs (c'est à dire que pour l'ASCII*, 'a'=97, 'b'=98, etc.).
 
 
Le coup des macros c'est franchement dégueulasse, mais je suppose que c'est parce que vous n'avez pas encore vu les fonctions.
 
Le mieux est de poster ce que tu as déjà fait, sinon ça va pas être facile d'aider
 
 
* par contre si c'est de l'EBCDIC y'a comme qui dirait des coupures  

 
 
Bonjour,
Merci de m'avoir répondu aussi vite.
Je vais te montrer où j'en suis mais tu vas rire parce que franchement j'ai pas fait grand chose...  
 
#include <stdio.h>
#include <string.h>
 
#define MAX 100
 
void remplace(char tab[])
{
  int i;
  for (i= 0;i<MAX;i++)
   {if (tab[i]=48)
     tab[i] = tab[i]+9;
   else
     {
     if ((tab[i]> 48) && (tab[i]<58))
       tab[i]=tab[i]-1;
      else
        tab[i]=tab[i]+1;
     }
   }
}
 
main()
{
  char text[MAX];
  printf("entrez un texte\n" );
  scanf("%[a-z,A-Z,0-9]40c",text);
  remplace(text);
  printf("\t Texte entre:\t %40c",text);
}
 
Voilà
Merci encore    

Tu as fait le plus dur.
 
Mais tu es tombée dans un gros piège qui est assez classique en C (et qui normalement génère un warning si je ne m'abuse...).
 
L'opérateur de comparaison est ==, pas = qui est l'opérateur d'affectation
 

 
Le genre de trucs qui fait bien mal aux dents
Pour éviter ça, essaie de toujours inverser les opérandes (c'est à dire 48==tab[i]), comme ça si tu oublie un = le compilateur génère une erreur.
 
EDIT: je regarde le reste du programme et j'éditerai au fur et à mesure.
Donc :
 
- en C, toute fonction, y compris main, doit avoir un type de retour explicite. Un prototype standard de main est "int main(void)" (et pas "void main()" comme on peut parfois le voir);
- comme main retourne un entier, il faut un "return 0;" à la fin;
- tu peux utiliser '0' (mais pas 0) au lieu de 48, etc.
- en C, une chaîne de caractère se termine par le caractère nul '\0' (qui est fait le nombre 0)
- une variable auto (comme text) n'est pas initialisée. Son contenu est indéfini (il correspond à ce qu'il y avait éventuellement sur la pile avant l'appel de la fonction). Donc le mieux est de faire :
 
char text[MAX] = {0};
 
pour initialiser son contenu à zéro.
 
 

Merci beaucoup pour tes conseils printf
Concernant les macros, pourrais tu m'aider?
 

Emploi & Etudes?
 
 
edit : poste dans le forum programmation

 
Euh, je viens de commencer moi aussi le C donc je suis un newbie dans ce domaine, mais à tout hasard ca serait pas plutot :
 
scanf("%[a-z,A-Z,0-9]40c",&text); ?
 

Non car text est déjà un pointeur.
 
(par contre c'est ultra-dégueu de lire des chaînes comme ça avec un scanf).

 
Ok autant pour moi j'aurais mieux fait de rien dire  

 
ça doit aussi pouvoir s'écrire comme ça :
 

C'est pas la peine de l'embrouiller avec cette syntaxe

Quand on débute c'est sûr ça peut sembler bizarre mais je trouve que ça file moins mal au crâne*
Une ligne est plus facile à comprendre que 4, même écrite comme ça.
 
* bon OK c'est peut-être les 60 Hz

 
Je préfère LARGEMENT la première version que la seconde entre nous hein...

Oui mais non.
Seul le résultat du test est conditionnel, pas l'opération. Donc cette construction est beaucoup plus appropriée.
Et c'est toujours bon de réduire la taille du code (dans cet exemple, tu gagne 5 lignes), car ça permet de faire tenir une fonction sur l'écran par exemple. Et dans le cas où c'est du code imbriqué, ça évite de rajouter des if et des else à n'en plus finir.
Donc y'a pas photo.
 
Après, c'est vrai que pour un TP c'est probablement de l'overkill et qu'il y a plus important pour l'instant que le style

 
C'est surtout que si tu connais pas lastructure de cet engin ( je l'ai pas rencontré souvent ), ton code, qui fait une opération simple, devient rapidement illisible et inmaintenable.
 
Je préfère scroller sur 4 lignes que me taper du code de ce type .

 
et on parle du manque de pédagogie de mon école  

 
la ca devient du snobisme quand même...

 
illisible et inmaintenable ? atta c kan même pas super compliqué comme "structure"

 
Si l'élégance est du snobisme, alors je dois avouer que je suis snob

+ pour Tetedeiench  
 
pour avoir souvent fait le pompier sur des usines à gaz écrites dans des langages que je ne maîtrisais pas forcement à 100% ... un bon vieux if else est quand même bien plus intuitif et claire
 
les syntaxes compressives, quelque soit le langage, je conseil toujours d'éviter. Entre la simplicité et se la péter il faut choisir, et un être bon codeur ce n'est pas exploiter la plus minime des bidouilles offerte par le langage
 
 
 
 

 
L'exemple est simple. Lemec qui te file ca partout sur tes 10 000 lignes de code, laisse tomber.

Le C est un assembleur portable, si vous voulez faire de l'art faites du Java et faites pas chier
 
Et de toutes façons, il est recommandé par les Prophètes, page 51 et 52 de la Bible, d'utiliser cette construction alors je vous merde

 
Ben non justement
Dans des if else imbriqués ou dans un printf c'est mieux d'utiliser ce genre de trucs.
 
Et puis on va pas débattre pendant 40 pages de ça. Je développe comme ça, et l'important c'est que les collègues comprennent...

 
je plussoie, une fois que tu l'as découverte cette syntaxe est bien plus agréable  
 
d'un autre côté je pense pas que ce soit le meilleur conseil à un étudiant qui débute  
 

 
c'est pas une critique, je te rappelle que je dois faire des progs en C a base de fonction qui font moins de 25 lignes de 80 colonnes chacunes

 
je parle pas non plus d'en imbriquer 4....
 
(koi ke, deja fait )

Désolé printf mais je dois intervenir : l'opérateur ternaire en plus de sa lisibilité moindre est également moins performant que le if-then-else car il oblige le compilateur à retourner une valeur.

 
Ca veut dire quoi qu'il oblige le compilateur à retourner une valeur ?

Prenons un exemple,
i?4:7 pour l'opérateur ternaire.
if i then 4 else 7 pour le if-then-else.
 
Dans les deux cas, i, 4, et 7 sont des expressions à calculer.
Mais pour l'opérateur ternaire, (i?4:7) est également une expression à calculer contrairement au if i then 4 else 7;
d'où le surcoût.

c'est comme l'histoire du ++i meilleur que i++, enfin, bon je m'égare là

 
Bah y a matière à débattre vu que tu le balances comme le messie sur ce topic à la base, et à un débutant en plus.
 
Bref. J'ai horreur des codes illisibles, des gens qui pour faire "lisibles" utilisent des constructions nécessitant un moment d'appréhension...
 
le if then else, en lecture, il se dit. ton ()?: je suis pas persuadé, t'vois. Alors que peut être que le gars habitué le lira vite. Mais le gars qui, comme moi, utilise pas ces ghorreurs ( et dieu sait queje dois pas être le seul), il préfère 100 fois un if then else que ce vieux truc.
 
Sincèrement, c'est du snobisme, une volonté, peut etre, de se rendre indispensable en rendant la compréhension de ce type de code difficile à quelqu'un de l'extérieur.
 
Bref, à éviter totalement. le if est plus verbeux, mais beaucoup plus lisible, et je préfère erdre du temps à scroller ou a taper 20 caractères et rendre mon code lisible ( bon pas jusqu'au niveau du COBOL hein ) plutot que de me la jouer geek qui maitrise et pondre un truc chiant à relire et à débugguer.

vancra, on est hors sujet n'est-ce pas ?

 
Ça veut dire quoi que "i ? 4 : 7" est une expression à calculer ? Le "i ? 4 : 7" il va être lu comme ça : si i est vrai alors on évalue 4 et on n'évalue pas 7, sinon on évalue 7 et on n'évalue pas 4. Je ne vois pas où est-ce qu'on "calcule" autre chose que "i" et "4" ou "7". Mais si t'as une référence précise comme un passage de la norme ou sur le comportement des compilateurs pour traduire cette expression en langage machine, ça m'intéresse (pour le dernier cas, ça se teste facilement en regardant le code assembleur produit, mais j'ai pas le courage de le faire ).
 
PS: comme on est HC, le modérateur pourrait déplacer le sujet vers Programmation.

 
Le passage de la norme en question (6.5.15, Conditional operator) indique ceci :
 

 
Sinon, j'aimerais un petit morceau de code machine, parce que j'ai comme un très très gros doute vis-à-vis de ce que tu raconte pains-aux-raisins
 
 
Pour les courageux, dans gcc/gcc/expr.c, fonction store_expr(), il y a le code qui génère du RTL à partir d'une telle opération.
Notez au passage ô combien les programmeurs de gcc sont des salopiots qui usent et abusent de cette syntaxe maléfique <-- Tetedeiench tu devrais aller leur dire que c'est pas lisible.

 
Ca correspond donc à ce que j'ai dit.
 

 
Moi aussi j'ai un doute.
 

 
avec le code de i$@.
 
Maintenant, il faut m'exposer un cas où le code assembleur produit n'est pas le même ET où il y a perte de performance dans le cas de l'utilisation de "? :".
 
 

 
Moi je trouve ça très lisible si c'est bien utilisé et bien aéré (comme le reste du code d'ailleur). Et c'est aussi bien pratique.

Euh, ca n'a un peu rien à voir, hein
 
i = 2;
toto[++i] <=> toto[3];
et toto[i++] <=> toto[2] et apres i = 3;
 
 

 
Il devait parler de cas où ça ne fait pas de différence a priori comme dans :
 

 
par exemple. En C++ on préfère ++i à i++ si la valeur de i n'est pas utilisée dans l'expression car le jour où "i" est un objet autre qu'un simple entier, on peut avoir une perte de performance non négligeable. Mais sinon, dans le cas de C en particulier, ça ne fait pas différence.

tu peux remplacer le bloc
 
void remplace(char tab[])
{
  int i;
  for (i= 0;i<MAX;i++)
   {if (tab[i]=48)
     tab[i] = tab[i]+9;
   else
     {
     if ((tab[i]> 48) && (tab[i]<58))
       tab[i]=tab[i]-1;
      else
        tab[i]=tab[i]+1;
     }
   }
}
 
par le bloc :
void remplace(char tab[])
{
  int i;
  for (i= 0;i<strlen(tab);i++)
   {if (tab[i]=='0')
     tab[i] = tab[i]+9;
   else
     {
     if ((tab[i]> '0') && (tab[i]<='9'))
       tab[i]=tab[i]-1;
      else
        tab[i]=tab[i]+1;
     }
   }
}
 
c'est plus lisible, peu de monde lise couramment la correspondance caractère ascii et valeur décimale
 
sinon la fonction strlen() permet de connaître la longueur de ta chaîne de caractère, cela t'évite de parcourir entièrement jusqu'à la longueur maximale

L'assembleur n'est pas (plus) mon truc, mais la literrature informatique peut être intéressante. Dans l'art de la programmation, il y a des chapelles... A savourer !
 
Best Practices for Programming in C : http://www-106.ibm.com/developerwo [...] nxw02BestC
 
Morceau choisi :

 
Plus en rapport avec l'opérateur ternaire :
 
Optimal C Constructs for 8051 Microprocessors : http://www.embedded.com/story/OEG20021015S0046
 
Où l'auteur dit :

 
Conclusion : l'opérateur ternaire est à utiliser en connaissance de cause.
 
Bon WE