bon je suis un peu perdu  
 
Taz m'avais dis %f et le man 3 printf l'a comfirmé  
 
or le C que j'ai appris et sur le site  http://www.iota-six.co.uk/c/c2_printf_and_scanf.asp, c'est %lf !!!!
 
 
deplus d'apres le man, le float a completement disparu ....
 
bon normallement je dois plutot croire le man de mon syteme  
 
j'etais au courant a propos des int qui pouvait prendre soit 2 ou 4 octets  
mais la bizzare, ca me surprends .....
 
 
sinon comment puis je savoir sur combien de bits sont les int sur mon systeme, y a t'il une page man ?  
je dois pouvoir utiliser des nombre de 0 à 2 ^(32) -1  
donc normallement ca passe juste juste en non signé mais je pense utiliser des long pour etre tranquille mais quel code format utilisé ? %l ???
 
 
 
 

je suis assez impressionné par le nombre de type de valeur qui existe sur mon systeme  
h => short int  
I => long int  
ii => long long int
L => long double
 
je pense que c'est un long int qui me faudrait mais comment connaitre les plges de nombre que je peux utiliser ou sinon la taille des variables.  N'existe t'il pas de page man pour avoir un peu plus de precisions ?

Pour un double c'est %f qui est utilisé, le 'l' n'est applicable que sur des entiers et est ignoré.
Pour connaître le nombre d'octets, tu peux utiliser sizeof().
Sinon, généralement sur unix de nos jours et sauf erreur de ma part, les longs et int sont sur 32, les long long sur 64, les short sur 16.
Tu peux aussi utiliser les séries int64, int32, int16 ...

En général (ce qui ne veux rien dire) les long sont 32 si compilés en 32 bits, et 64 si compilés en 64 bits. En général toujours, les int font 32 bits et les long long 64 bits, quel que soit le mode.
 
Pour connaître la taille en bits d'un type, fait « sizeof (type) * CHAR_BIT » (et oui, un char ne fait pas forcément 8 bits). Si tu veux juste savoir la plus grande quantité que peux contenir un type de base, utilise les INT_MAX, UINT_MAX...
 
Tout ça est dans limits.h et dépend de l'architecture.
 
Ah et puis pour réponde à ta question, ce n'est pas %l pour les long mais %ld ou %lu, suivant que tu veux du signé ou non signé. Et pour long long c'est %lld ou %llu. Les « l » et « ll » sont des modificateurs qui s'insèrent avant le type qui suit (d, u, x, X).

int32 t; n'a pas l'air de trop passer ...

 
 
je viens de faire un petit sizeof vite fais et en effet tu as raison  
int et long => 32
long long => 64
mais alors a quoi ca sert le int ?
les bornes de int et de long sont bien  
0 -> 2^32 en non signé
ou en signé de - 2^32/2 -> 2^32/2

oulala je me suis fais grilled
je regarderais ca demain  
merrci pour vos reponses

 
weed > en fait, c'est simple, c'est juste que le format diffère à l'affichage et à la saisie
 
affichage -> %f pour les double et float (puisque le double va être converti)
lecture -> double %lf , float %f
 
vivelec > et me sort pas que c'est pas standard

pas portable donc. y a tout ce qu'il faut en C99 dans <stdint.h>

 
et ya pas un truc qui s'appelle la promotion des parametre et qui converti les float en double ou c'est juste c pre ansi (k&r) ?

oups j'ai fait une erreur
 
-> (puisque le double^Wfloat va être converti)  
 
si. mais uniquement en entrée évidemment, ton float* tu peux le faire passer en double*, mais ça cassera. dans l'autre sens aussi.

ok

Tout dépend de tes standards ...
Sous UNIX et non sous linux, effectivement ce n'est pas "standard", du moins, le 'l' est ignoré.

oki je comprends mieux  
merci a vous tous ...
 
j'ai fais comme a dis matafan :

 
mais que vois je :

int = long = (2^32)/2-1
est ce que je me suis trompé ?
sinon pour info :

Qu'est-ce qui ne te semble pas normal ?

et allez, ça repart ... non mais non seulement de raconter des conneries tu dis des trucs dangereux. et tu te dis expert ? et ben mon Dieu !
 
%lf est tout a fait standard et ANSI
 
tu commences à nous saouler : ON EN A RIEN A FOUTRE SI T'ES TROP NUL POUR T'INSTALLER UN COMPILATEUR C

rien, sur système 32 bits, il se trouve que sizeof(long) == sizeof(int)

Qu'est-ce qu'elle a la petite merde ?
T'as tes règles ?
Prends du spafon cocotte et fais pas chier.
 

Et je dirais que petite merde encore, sur 64 bits c'est la même chose.
Il n'y a plus de distinction entre le int et le long depuis que l'on a tous migré sur des archis en 32 bits.

 
ce serait cool de rester poli.
 

Ce n'est qu'un échange de bon procédés avec Taz.
Rien de bien méchant.

"Qu'est-ce qui ne te semble pas normal ? "
 
ce que retourne INT_MAX et LONG_MAX c'est qui me chagrine :
  INT_MAX 2147483647, UINT_MAX 4294967295, LONG_MAX 2147483647
 
long sert strictement a rien alors ???? si c'est tous les 2 : 2147483647
c'est bien 32 bits 2^32/2-1, je pensais que la taille ne voulait rien dire du fait que int ne soit pas compilé et le long compilé et que INT_MAX < LONG_MAX
 
mais il y a un long beaucoup plus long (ouou, le jeux de mots )  

et puis SVP, restez calme  
je ne sais pas qui a raison, mais que vous avez tous les 2, vivelec et taz, un tres tres bon niveau en linux/unix

Ce n'est pas une question d'avoir un bon niveau ou non, les métiers de l'informatique sont diverses et à chacun sa spécialité.
Cependant, la courtoisie et le respect sont des minimums, tant qu'ils sont réciproques.
Ce qui n'est pas toujours le cas.

Cela ressemble à du linux.
Il est préférable d'adopter des conventions héxas pour tout ce qui a trait à du binaire.

"Il est préférable d'adopter des conventions héxas pour tout ce qui a trait à du binaire. "
 
dsl mais je comprends pas du tout  
ou vois tu de l'hexa et pourquoi me parle de binaire ?

Tu remarqueras par exemple que 9223372036854775807L correspond à 7FFFFFFFFFFFFFFF qui correspond donc à la valeur max d'un 64 bits signé, soit -9223372036854775807 à +9223372036854775807.
Sur un 64 bits non signé, tu aurais droit à la plage 0 - 18446744073709551615.
Sur la majorité des plateformes, le bit de signe est en effet positionné sur le bit de poids fort.
Généralement, pour tout ce qui a trait à la manipulation de bits ou d'octets, on choisit l'octal ou l'héxa.

mais dis donc, tu me parais avoir une sacré expérience mon gars ... manqué sur beaucoup d'architecture 64bits, l'int fait 32bits et le le long fait nativement 64bits.

ah ouais, moi aussi, je reconnais cette manière d'indenter.
 
weed > il est bizarre ton limits.h ...
 
cela dit, la norme impose que sizeof(int) <= sizeof(long) <= sizeof(long long)
 
sur X86 32bits, l'int et le long font 32bits, le long long 64bits, le contrat est respecté

Es-tu vraiment sûr de ce que tu annonces ?
Ceci dit, je commençais à déspérer de ton absence.
Mais suis-je bête, on est jeudi, jour de congé pour les estudiantains !
Tes injures m'ont manquées à vrai dire.
Encore !

oui

En fait, et là, si tu as les preuves qui vont bien et pas sur linux, stp, les int et les longs sont codés sur 32 bits quelque soit la plateforme.
Ceci dit, j'aurais tendance à croire la même que toi.

K&R. il a juste une relation d'ordre imposé entre les tailles et des capacité minimales à fournir. on trouve donc des architectures où sizeof(int) == 4 et donc sizeof(long) == sizeof(void*) == 8

et bien en tout cas  
je suis vraimenent decu  
j'ai eu l'occasion de programmer sur du C borland sous win32sur une  architecture 32 bits, c'est peut etre pas du C trop standard mais le long etait plus long que ca ...  
 
bon allez bonne nuit

Vérifie par toi même, mais sizeof(void) n'est pas égal à 8 en dehors de linux.

déjà je parle de sizeof(void*) et sur un système 64bits, encore heureux que sizeof(void*) == 8

 
tiens :
http://www.codeproject.com/cpp/FastDelegate.asp
 
matte un coup le chapitre "Implementations of Member Function Pointers"
la colonne "DataPtr"
 
 
[edit] oups, c'est du C++, mais bon la remaque reste valide

ah ben non, et ho, les systèmes 64bits, faudrait pas non plus qu'ils puissent addresser 64bits

Donne-moi alors un vrai os 64 bitd, et je teste.
Rien ne vaut l'empirisme ..

Oups, j'oubliais, tout sauf linux.