Bonjour a tous    
 
Voila j'ai quelque questions ou je n'ai pas trouvé de réponse..
 
 
1/ Peut on utiliser int pour mettre un caractère exemple A ?
 
2/ Pourquoi dans ce code on met i-- au lieu de i-1, c'est pas pareil ?
 

 
3/ Pourquoi dans la fonction strcat dans chaine1 il y a un espace entre le "t" de Salut et le "\0 ?
 
L'image se trouve a cette adresse: http://www.hiboox.fr/go/images/div [...] 9.png.html

Franchement, t'aurais pus poser tes question dans l'autre topic que t'as ouvert : http://forum.hardware.fr/hfr/Progr [...] 8355_1.htm
 
1) oui
2) i--; et i = i - 1; sont équivalents en terme de résultat sauf qu'il me semble que i-- est plus rapide mais ça se joue pas à grand chose et avec les compilos modernes doivent faire ce genre d'optimisation. Attention à pas confondre avec --i;
 
3) sans le code, je peux pas répondre.

1) un caractère, comme 'A', est en fait un code ASCII, représentable sous forme d'un entier (41 pour 'A'). Donc oui, tu peux utiliser un entier pour mettre un caractère.
Après, compare un sizeof(int) et un sizeof(char) et vois lequel doit être utilisé de préférence pour stocker un caractère  
 
2) cf post de rufo
 
3) J'ai envie de te demander : pourquoi pas ? Le caractère espace est un caractère comme un autre. Imagine que tu veux afficher le nom de l'utilisateur, contenu dans une autre variable, après le "Salut ". Si tu ne fais pas figurer d'espace entre les deux, ça va être moche (et tu ne vas pas stocker un espace devant le nom de l'utilisateur). Ne te prends donc pas la tête avec des questions comme celles-ci, y'a déjà bien d'autres choses à penser

En C, le type naturel pour un caractère, c'est int (cf. fonctions standards comme strchr par exemple) :

Attention, en C++, le type naturel d'un caractère, c'est bien char :

Pour la question 3 c'est ok car j'ai pas vu l'espace ici : chaine1[100] = "Salut "

Ok, donc dans un "char", c'est juste l'adresse de l'int correspondant qui est stockée ?

Merci pour les questions précédente.. c'est ok !!

J'ai une autre question :

Une case mémoire, sur un ordinateur correspond à un octet (8 bits), donc le nombre 145 sera stocké et traduit en binaire qui donnera 10010001 (dans une case), et si je veux stocké le nombre 37120 il faudra qu'il regroupe plusieurs cases d'un octet ?

 
Non, c'est la valeur du caractère, tout simplement. De toute façon j'ai jamais bien compris pourquoi en C les caractères étaient des int, alors que les "chaînes" de caractères étaient des char*.

Quand tu définis une variable pour stocker des entiers, tu as différents types disponibles, qui diffèrent justement sur le nombre d'octets utilisés. Si tu veux stocker ton "37120" dans un entier sur 1 octet, effectivement, ca va pas aller (à priori, y aura que les 8 derniers bits, donc 0 ici). Si tu le mets dans un entier sur 2, 4 ou 8 octets, ca ira  
A toi donc de bien choisir les types de données utilisés.

Non, dans un char, c'est la valeur de l'int qui est stockée.
A+,
Edit: grilled parce que je suis parti bouffer sans faire un post de ma réponse

Oui et non. En vrai, la "plus petite entité adressable" (c'est la définition), c'est un "byte".
Il se trouve qu'à l'heure actuelle, 99.99% (100% ?) du parc informatique à un byte valant 8 bits, donc un octet.
Mais ce n'est pas pour autant qu'un byte == un octet. Il y a eu des machines avec des bytes différents de 8 bits, par exemple le PDP-1, où 1 byte valait 18 bits. À l'avenir, rien ne garanti que nous n'aurons pas des machines avec 1 byte = 16, 32, 64 ou whatever bits.

La remarque est pertinente, mais il est plus simple de raisonner en plage de nombres.
En C, la norme ISO défini des plages de nombre minimum, c'est-à-dire que selon les machines, ces plages peuvent être plus grandes, mais jamais plus petites.
Selon la norme (pour les types signés) :
char = -128 -> +127
int = -32 768 -> +32 767
long int -2 147 483 648 -> +2 147 483 647
etc.

A mon avis, juste pour reconnaitre, quand tu vois char*, que tu as une chaine, et que quand tu vois int*, tu as des données utilisées autrement. Bref, en C, pour la lisibilité et la maintenance des programmes. Bon, il y a aussi une question de taille de données.  
A+,

  (et à Gilou aussi )
 
C'est le coup du sizeof('A') = 4 bits qui m'a fait me poser la question

Tu confonds la notion de mot machine [word] (ie la zone entre ce que pointent les adresses @ et @+1) et la notion d'octet [byte] qui fait toujours 8 bits.
En C, le type int a pour taille un word, et le type char a pour taille un byte.voir plus bas.

A+,

Hmm, non. Byte n'est pas le mot anglais pour "octet". Si aujourd'hui toutes nos machines (à ma connaissance, j'ai aucune idée du nombre d'architectures embarquées qui existent ) ont un byte de 8 bits, ça n'a pas toujours été le cas, et ça ne sera peut-être pas le cas dans le futur.

Par contre je te rejoins sur ta dernière phrase : sizeof(char) vaut toujours 1 en C d'après la norme, soit 1 byte. Et ce quelle que soit l'architecture.

Oui, j'ai dit une connerie, car de plus j'ai bossé sur des bécanes ou le byte avait 7 ou bien 12 bits il me semble bien
Un byte est l'unité de stockage mémoire, la zone entre ce que pointent les adresses @ et @+1. Un char a par définition pour taille 1 byte.
Historiquement (K&R) un int avait pour taille la taille d'une adresse mémoire (non basée), et quand j'ai commencé le C, il n'était pas rare de voir du code ou un int servait à ranger une adresse. Bref, un int avait la taille d'un pointeur. Ensuite, en particulier avec les adressages biscornus de l'architecture segmentée x86 ça n'a plus été exactement ça.
Bref, la norme actuelle dit simplement que la taille d'un int est ce qui convient le mieux a l'architecture de la bécane
Elle demande que char <= short <= int <= long soit respecté et impose des range (ou taille?) minimum aux types char et int.
Bon, je constate néanmoins que sur mon compilo C, j'ai toujours sizeof(int*) = sizeof(int) néanmoins
A+,

 
L'histoire.  Le BCPL était un langage non typé.  Le seul élément manipulé était le mot.  Normal à une époque (1966) où les ordinateurs se classaient en commerciaux (adressable par caractère et ne manipulant les nombres qu'en BCD) ou scientifique (adressable par mot de 36 bits ou plus et mauvais en manipulation de caractères) en plus des mini qui commencaient. Les caractères isolés étaient donc des mots, les chaines désignaient l'adresse d'un tableau de mots dans lequel étaient compactés les caractères (à raison de 6 caractères de 6 bits par mot de 36 bits par exemple).  L'espace mémoire était plus réduit (18 bits d'adresse par exemple pour des machines avec mot de 36 bits, ça fait 256K mots) et on ne perdrait pas de la place à mettre un caractère par mot.
 
[quotemsg=1980544,11,14993]Oui et non. En vrai, la "plus petite entité adressable" (c'est la définition), c'est un "byte".[/quote]
 
Oui et non.  C'est un des trois sens de byte.  L'original, c'est la taille nécessaire à stocker un caractère.  Le troisième, c'est 8 bits.  L'extension de sens c'est faite parce que les trois vont de plus en plus ensemble.
 
Le C et le C++ confondent effectivement les deux premiers.  Mais un byte peut y faire plus de 8 bits, pas moins.  Ces langages sont quand même conçu pour permettre une implémentation où on a un byte plu
 

 
Sur les machines adressables par mot, on a utilise rarement le sens "plus petite unité adressable" pour byte.  Dans leur contexte, byte est toujours la place prise par un caractère (et on peut se retrouver avec un byte de 7 bits et des mots de 36 bits, en laissant un bit inutilisé quand on compacte les caractères).  Sans parler de celles qui comme Stretch étaient adressable par bit bien qu'adressable par mot.
 
En passant, on utilise toujours des machines adressables par mot.  Outre chez les nostalgiques et les englués, les DSP le sont souvent. Pour revenir au C et au C++, je m'attendrais à ce qu'une implémentation "historique" sur une machine adressable par mot fasse usage des lattitudes laissée pour avoir void* et char* (composé d'une adresse de mot et d'une indication d'un caractère dans le mot) plus grand que les autres pointeurs (avec short* éventuellement).  Une implémentation sur DSP aura plus facilement le byte égal au mot.
 
Allez, j'arrête de radoter sur une époque dont je n'ai connu que le crépuscule (j'ai de justesse utilisé un PDP-10, alors que sa fabrication n'était pas encore abandonnée par DEC).

Tu aurais fait  
printf("%d - %d - %d\n", sizeof(1), sizeof('A'), sizeof((char)'A'));
-> 4 - 4 - 1 chez moi
ca aurait été plus explicite.
A+,

Évidemment, la discussion a continué pendant que je radotais.
 

 
Pas nécessairement (pas mal d'archi adressable par mot n'ont pas un espace d'adressage égal au mot, elles ont même parfois des registres d'adresse plus petit -- voir les Cray par exemple).
 

 
Moi pas (le premier fait 64 bits, le deuxième 32; c'est le cas pour Unix 64 bits depuis 15 ans)

oula je mélange tout...
 
Qui peut m'expliqué comment les variables de type char, int long, float, et double sont stocké dans la mémoire en binaire ?

 
N'essaye pas trop de nous suivre quand on radote...
 

 
En laissant tomber les organisations historiques et exotiques.
 
La mémoire c'est des cases numérotées permettant de contenir un nombre de 0 à 255 (ou 8 bits).
 
Une variable de type char prend une case.
int, 4 cases consécutives
long 4 ou 8 cases (32/64 bits au moins pour Unix, Windows a les long sur 32 bits même en 64 bits)
float 4 cases
double 8
 

J'ai jamais eu l'occasion de programmer sur Cray (par contre sur PDP, sous multics   )
Sinon, c'est pour ça que j'avais précisé mon compilo, sachant bien que ce n'était pas le cas de tous
A+,

 
Petit cadeau: http://web.mit.edu/multics-history [...] urces.html (il manque une section PL/I).

 
A+,

 
J'ai appris plein de trucs ce soir, merci.

Notes que si on veut rester dans le cadre du C++, j'aime bien ce qui est dit ici, en particulier au 26.6, sur comment des compilos C++ différents pourraient avoir des bytes de taille différentes sur une même machine:
______________________________________________________________________________________________________________________________________________________
[26.1] Can sizeof(char) be 2 on some machines? For example, what about double-byte characters?
 
No, sizeof(char) is always 1. Always. It is never 2. Never, never, never.
Even if you think of a "character" as a multi-byte thingy, char is not. sizeof(char) is always exactly 1. No exceptions, ever.
 
[26.2] What are the units of sizeof?
 
Bytes.
For example, if sizeof(Fred) is 8, the distance between two Fred objects in an array of Freds will be exactly 8 bytes.
As another example, this means sizeof(char) is one byte. That's right: one byte. One, one, one, exactly one byte, always one byte. Never two bytes. No exceptions.
 
[26.3] Whoa, but what about machines or compilers that support multibyte characters. Are you saying that a "character" and a char might be different?!?
 
Yes that's right: the thing commonly referred to as a "character" might be different from the thing C++ calls a char.
I'm really sorry if that hurts, but believe me, it's better to get all the pain over with at once. Take a deep breath and repeat after me: "character and char might be different." There, doesn't that feel better? No? Well keep reading — it gets worse.
 
[26.4] But, but, but what about machines where a char has more than 8 bits? Surely you're not saying a C++ byte might have more than 8 bits, are you?!?
 
Yep, that's right: a C++ byte might have more than 8 bits.
The C++ language guarantees a byte must always have at least 8 bits. But there are implementations of C++ that have more than 8 bits per byte.
 
[26.5] Okay, I could imagine a machine with 9-bit bytes. But surely not 16-bit bytes or 32-bit bytes, right?
 
Wrong.
I have heard of one implementation of C++ that has 64-bit "bytes." You read that right: a byte on that implementation has 64 bits. 64 bits per byte. 64. As in 8 times 8.
And yes, you're right, combining with the above would mean that a char on that implementation would have 64 bits.
 
[26.6] I'm sooooo confused. Would you please go over the rules about bytes, chars, and characters one more time?
 
Here are the rules:
 
    * The C++ language gives the programmer the impression that memory is laid out as a sequence of something C++ calls "bytes."
    * Each of these things that the C++ language calls a byte has at least 8 bits, but might have more than 8 bits.
    * The C++ language guarantees that a char* (char pointers) can address individual bytes.
    * The C++ language guarantees there are no bits between two bytes. This means every bit in memory is part of a byte. If you grind your way through memory via a char*, you will be able to see every bit.
    * The C++ language guarantees there are no bits that are part of two distinct bytes. This means a change to one byte will never cause a change to a different byte.
    * The C++ language gives you a way to find out how many bits are in a byte in your particular implementation: include the header <climits>, then the actual number of bits per byte will be given by the CHAR_BIT macro.

Let's work an example to illustrate these rules. The PDP-10 has 36-bit words with no hardware facility to address anything within one of those words. That means a pointer can point only at things on a 36-bit boundary: it is not possible for a pointer to point 8 bits to the right of where some other pointer points.
 
One way to abide by all the above rules is for a PDP-10 C++ compiler to define a "byte" as 36 bits. Another valid approach would be to define a "byte" as 9 bits, and simulate a char* by two words of memory: the first could point to the 36-bit word, the second could be a bit-offset within that word. In that case, the C++ compiler would need to add extra instructions when compiling code using char* pointers. For example, the code generated for *p = 'x' might read the word into a register, then use bit-masks and bit-shifts to change the appropriate 9-bit byte within that word. An int* could still be implemented as a single hardware pointer, since C++ allows sizeof(char*) != sizeof(int*).
 
Using the same logic, it would also be possible to define a PDP-10 C++ "byte" as 12-bits or 18-bits. However the above technique wouldn't allow us to define a PDP-10 C++ "byte" as 8-bits, since 8*4 is 32, meaning every 4th byte we would skip 4 bits. A more complicated approach could be used for those 4 bits, e.g., by packing nine bytes (of 8-bits each) into two adjacent 36-bit words. The important point here is that memcpy() has to be able to see every bit of memory: there can't be any bits between two adjacent bytes.
 
Note: one of the popular non-C/C++ approaches on the PDP-10 was to pack 5 bytes (of 7-bits each) into each 36-bit word. However this won't work in C or C++ since 5*7 = 35, meaning using char*s to walk through memory would "skip" a bit every fifth byte (and also because C++ requires bytes to have at least 8 bits).  
______________________________________________________________________________________________________________________________________________________
( http://www.parashift.com/c++-faq-l [...] l#faq-26.4 )
 
A+,

mais moi je veux juste savoir si le type short (2 octets) occupe 1 ou 2 case en mémoire !

Si tu dis que ça fait deux octets, c'est que ca occupe deux cases mémoires, hein.
 
Globalement, ca dépend des plateformes et compilateurs. La seule chose dont tu puisse être sur c'est que:
 sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
 sizeof(short) >= 2
 sizeof(int) >= 2
 sizeof(long) >= 4
 
Concrétement, le plus souvent tu as sizeof(short) = 2.
 
De toute façon, je ne vois pas trop pourquoi tu poses la question, vu que ça devrait avoir aucune influence sur ce que tu programmes.
A+,
 

 
Sur les machines que tu utilises, probablement.  Ce n'est pas garanti par le langage et des exceptions existent, même hors du champs de l'archéo-informatique.
 
(Note que short ne fait pas nécessairement 2 octets; sur un DSP avec des mots de 24 bits, l'implémentation naturelle serait char, short, int sur 24 bits et long sur 48 bits).
 

 
Tu peux ajouter sizeof(char) == 1  
 

 
Pas vrai.  J'ai pas joué avec mais il y a quelqu'un sur comp.lang.c qui utilise une machine avec sizeof(long long)==1 (je me demande si ce n'est pas à nouveau un Cray).  
 

 
+1, mais c'est fou le nombre de gens qui aiment dépendre de détails quand les ignorer simplifierait leur vie.

bonjour je voudrais que vous m'aidiez a développez un programme qui fait la somme de deux grand nombre que l'utilisateur les entre comme des chaines de caractère j'ai essayé de faire le programme m'ai je n'arrive pas à trouver l'emplacement de l'erreur je vous pris de m'aider le plus vite possible
voici mon code:

#include <stdio.h> 
#include <stdlib.h> 
#include<string.h> 
 
int convertir(char *ch,int n); 
main() 
{char ch1[40],ch2[40]; 
  int nb1,nb2,n,m,i=9,cos=0,max,t[10]={0}; 
  printf("entrer le premier nombre:" ); 
  scanf("%s",ch1);n=strlen(ch1); 
  printf("entrer le deuxieme nombre:" ); 
  scanf("%s",ch2);m=strlen(ch2); 
  /*max=(n>m)?n:m; 
    d=max/4+3; 
    t=(int*)malloc(d*sizeof(int));*/ 
  while(n>=0 || m>=0) 
    {nb1=convertir(ch1,n); 
      nb2=convertir(ch2,m); 
      t[i]=(nb1+nb2+cos)%10000; 
      cos=(nb1+nb2+cos)/10000; 
      n-=4;i--; 
      m-=4; 
    } 
  for(i=0;i<10;i++) 
    printf("%4d",&t[i]); 
  getch(); 
} 
 
 
int convertir(char *ch,int n) 
{int i,j=3,nb=0; 
  char temp[5]; 
  if(n>0) 
    { 
      for(i=n-1;i<=n-5;i--) 
        {temp[j]=ch[i]; 
          j--; 
        } 
      temp[4]='\0';nb=atoi(temp); 
    } 
  return(nb); 
}

et merci d'avance

Ce qui ne vous autorise en rien à squatter le topic des autres. Créez le vôtre si vous souhaitez une réponse.