Journal : Les enfants, un grand moment de l'Histoire se prépare...
Posté par Sixel (page perso, ) le 09 juin 2005
... mais il va falloir attendre un siècle!
Plus exactement, 99 ans tout pile, jusqu'au 9 juin 2104.
Vous voyez toujours pas de quoi je parle? Un petit indice? Ben ça se passera très exactement le 9 juin 2104 à 05:10:42 du matin...
Toujours pas la moindre idée? Histoire de pousser un peu plus loin la précision, et de vous donner un nouvel indice, l'évènement tant attendu aura lieu le 9 juin 2104 à 05:10:42 et 424 millièmes du matin!
Comment ça vous avez toujours pas deviné?!?! Mais quelle epoch vivons-nous, c'est incroyable l'inculture des jeunes gens de nos jours...
Plus exactement, 99 ans tout pile, jusqu'au 9 juin 2104.
Vous voyez toujours pas de quoi je parle? Un petit indice? Ben ça se passera très exactement le 9 juin 2104 à 05:10:42 du matin...
Toujours pas la moindre idée? Histoire de pousser un peu plus loin la précision, et de vous donner un nouvel indice, l'évènement tant attendu aura lieu le 9 juin 2104 à 05:10:42 et 424 millièmes du matin!
Comment ça vous avez toujours pas deviné?!?! Mais quelle epoch vivons-nous, c'est incroyable l'inculture des jeunes gens de nos jours...
> Lire le journal (52 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #586326.
Run by 
Cette page a été générée par Templeet en 0.0864s (dont 0.0091 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
May the 64bits be with you !
Il se sera écoulé 2^32 secondes depuis le 1er janvier 1970. Mais d'ici là, toutes les bécanes seront, au moins, en 64bits, je ne me fait donc pas trop de soucis ! ;-P
[^]Re: May the 64bits be with you !
Je pensais que c'était la date où apple changerait de fabriquant de puce pour retourner chez IBM.
"Nobody expects the spanish inquisition"
[^]Re: May the 64bits be with you !
Mais non. Ce sera le deuxieme tour du vote pour le TCE.
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: May the 64bits be with you !
Ah, je croyais que ça serait la date de sortie de la prochaine Debian...
J'arriiiiiiiiiive =======>[]
In tartiflette we trust !
[^]Re: May the 64bits be with you !
Ca suffit pas de passer au 64b bits. Sous linux, le type time_t est en fait un 'long int'. Donc si de base le 'long int' n'est pas codé sur 64 bits, ou si le type de 'time_t' n'est pas modifié, alors tu as perdu.
Malheureusement je n'ai pas de machine 64 bits sous la main pour vérifier, mais j'aurais tendance à penser que le long est toutjours codé sur 32 bits, alors que le 'long long int' est lui codé sur 64.
[^]Re: May the 64bits be with you !
si de base le 'long int' n'est pas codé sur 64 bits
Il me semble si j'ai bien suivi mes cours de C qu'un int correspond a un entier codé sur 16 bits pour un proc 16 bits, 32 bits pour un proc 32 bits, et sur archi 64 bits, ca correspond a 64 bits.
Donc un long int devrait faire 128 bits sur archi 64 bits.
....
[^]Re: May the 64bits be with you !
le int s'arrete a 32b, meme sur un proc 64b.
[^]Re: May the 64bits be with you !
URL ?
Ce que j'avais retenu, c'est
char < short int
short int <= int
int <= long int
long int < long long int quand ça existe.
En général int a le nombre de bits du bus de données de l'architecture. Parfois c'est tombé sur un nombre qui n'était pas une puissance (entière) de 2.
[^]Re: May the 64bits be with you !
En fait pour etre plus precis, la taille des short, int, ... peuvent varier d'un compilateur et d'une plate-forme a un autre. Sur solaris, le int est sur 32b par exemple. Le mieux est de ne pas faire de supposition sur la taille d'un int.
[^]Re: May the 64bits be with you !
euh, si j'ai bonne memoire, c'est plutot
char <= short int
C'est comme ca qu'on peut se retrouver avec une archi ou :
char == short int == long int == int
Le truc amusant c'est de faire une pile UDP/TCP/IP avec ca. Vous aimez les masques et les decalages ? (oui, c'est du vecu)
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[+] [^]Re: May the 64bits be with you !
Ah, enfin quelqu'un qui ne dit pas une ânerie sur le C.
Donc, pour résumer, en C, seule la taille du type char est garantie par la norme : un octet, soit un byte de 8 bits.
D'ailleurs, le fait que les bytes fassent 8 bits sur l'architecture proposée est la condition sine qua none à toute implémentation du langage.
flure
[^]Re: May the 64bits be with you !
Tu dis absolument n'importe quoi.
Tu confonds byte et octet. La taille du char n'est pas garantie; ce qui l'est c'est sizeof(char) == 1 byte ce qui est bien différent. Par contre un char doit faire au moins 8 bits c'est indiqué par la section 5.2.4.2.1 du C99 avec la macro CHAR_BIT. CHAR_BIT défini combien il y a de bits dans un byte.
Si tu veux des types de taille connu tu utilises le C99 et les types défini dans <stdint.h>
[^]Re: May the 64bits be with you !
Euh, pour ma culture personnelle et comme il n'est jamais trop tard pour apprendre : c'est quoi la différence entre byte et octet ? (Dire que j'ai réussi à avoir quatre diplômes d'enseignement supérieur en informatique en croyant que ces deux mots désignaient la même chose, à savoir 8 bits. Quelle honte pour moi et pour le système universitaire de ce pays...)
[^]Re: May the 64bits be with you !
Question difficile dans le sens général mais ici on parle de la signification de Byte dans le langage C.
L'article de wikipédia donne une bonne base, http://en.wikipedia.org/wiki/Byte(...) . La clause qui défini le byte est celle-ci : "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment" [1]. Comme indiqué plus haut la taille minimale d'un byte est de 8, il n'y a pas de taille maximale. On connait la taille sur l'environement courant à l'aide de CHAR_BIT. Il me semble que la traduction française de byte est multiplet.
L'octet, en français ou en anglais, est un groupe de 8 bits.
> Quelle honte pour moi et pour le système universitaire de ce pays...
Les profs sont bien trop occupés à expliquer qu'il faut initialiser ses données ou allouer sa mémoire. Le C est souvent considéré comme facile car il y a peu de concepts de haut niveau. On peut coder un "Hello world" sans avoir besoin de 25h de cours théorique pour comprendre ce que l'on fait [2]. Pourtant c'est un langage très, trop, complexe avec une norme imbitable issu de 30 ans de normalisation, des comportements à la con partout [3]. Le C c'est le Pentium des langages. C'est pourri mais tout le monde utilise.
[1] Pour le folklore undefined behavior et unspecified behavoir sont défini avant le byte, tout l'état d'esprit du C :-)
[2] Essayez d'expliquer chaque ligne d'un Hello World en java...
[3] S'en chercher bien loin, défninir le comportement de fonctions basiques telles que snprintf/strncat/strncpy sans s'aider de la page de man.
[+] [^]Re: May the 64bits be with you !
Tu confonds byte et octet
Relis ce que j'ai écrit : "un octet, soit un byte de 8 bits." C'est pas clair ?
Sinon pour le reste il me semble que je dis la même chose que toi.
flure
[^]Re: May the 64bits be with you !
> D'ailleurs, le fait que les bytes fassent 8 bits sur l'architecture proposée est la condition sine qua none à toute implémentation du langage.
Bha non c'est totalement faux
http://www-s.ti.com/sc/psheets/spru034h/spru034h.pdf(...) page 101. Un exemple de plateforme sur lequel les char sont sur 32 bits.
La dessus sizeof(char) == sizeof(short) == sizeof(int) == 1. Et un byte fait 32 bits.
[+] [^]Re: May the 64bits be with you !
Pardon.
Je voulais dire au moins 8 bits
flure
[^]Re: May the 64bits be with you !
Alors le C99 dit exactement ca (je résume un peu)
Les implémentations doivent fournir des types qui couvrent AU MOINS ces plages de valeurs la:
short : -32767 .. +32767
int: -32767 .. +32767
long: -2147483647 .. +2147483647
Ces valeurs sont contenues dans (SHORT|INT|LONG)_(MIN|MAX) dans <stdint.h>
Après les implémentations peuvent faire ce quelles veulent. On notera aussi une référence qui indique que le int devrait de préférence est le mot machine (avec la contrainte énnoncée ci dessus).
Ainsi on a un short qui est au moins sur 2 octets, et pas bytes, un int est aussi au moins sur 2 octets un long au moins sur 4.
> Donc un long int devrait faire 128 bits sur archi 64 bits.
Rien est moins sur. Il n'y a aucune mention d'un type 128 bits dans le C99. Les plus grand que l'on trouvent sont le long long qui lui est obligatoirement sur au moins 64 bits et le int64_t qui lui est exactement sur 64 bits (un long long correspondant à un int_least64_t).
[^]Re: May the 64bits be with you !
Non justement le long sous unix correspond a la longeur d'un mot machine (donc en 64bits, 64bits) par contre le long long reste sur bien des plateformes 64bits. Et seul le int reste en 32bits.
Par contre sous windows (histoire d'emmerder le monde) le long reste 32bits (il faut alors utiliser le tres portable __int64)
[^]Re: May the 64bits be with you ! time_t fait pour cela
Sous linux, le type time_t est en fait un 'long int'.
Ouais enfin c'est pas bien dur de changer le typedef pour en faire ce qu'on veux !
C'est même d'ailleurs exactement pour cela que time_t est utilisé, et pas autre chose.
[^]Re: May the 64bits be with you !
linux/gcc
p4:
int:4
long int:4
long long:8
long long int:8
amd64:
int:4
long int:8
long long:8
long long int:8