Certes et 10.7 ? Dans deux ans, tu réécrits toutes tes applications. :rateau:
10.6 supporte ces technologies car des nombreuses vieilles applications les utilisent mais si Adobe se casse le c... à réécrire ses applications alors qu'ils ne l'ont pas fait depuis bientôt 10 ans qu'existe Mac OSX, c'est qu'ils doivent avoir une bonne raison. Ils ont peut être plus d'infos que toi
Se casse les quoi ? Si tu écris les mots à moitié, on ne va pas te comprendre
Désolé, je n'ai toujours pas compris ce que veut dire 64 bits et 32 bits. Quand on déclare un int il sera 64 bits et non plus 32. Qu'est ce que cela change... ?
C'est le code qui sera 64 bits et prendra deux fois plus de place ? Quels sont les gains ?
Eh, Tatouille, explique nous !
Cordialement
La taille des int
(entiers naturels), des long et des pointer
(alias void*), se voient attribués individuellement soit une taille de 32 bits soit une taille de 64 bits.
Cette assignation dépend du compilateur et du système d'exploitation cible. Mais en pratique, l'OS et le compilateur sont aussi étroitement liés que par contrat
(un OS = un compilateur officiel), et on peut le plus souvent de référer à l'OS et à implicitement un compilateur
(ou une configuration d'un compilateur).
Il existe plusieurs combinaisons possibles, mais deux d'entre elles
(en dehors de plus exotiques) sont plus fréquentes : la convention Windows et la convention UNIX.
Sous
Windows 64, int et long font 32 bits, pointer fait 64 bits.
On fait référence à cette convention, sous le terme
IL32P64
Sous
UNIX 64, int fait 2 bits, long et pointer font 64 bits.
On fait référence à cette convention, sous le terme
I32LP64
Personellement, je trouve la convention de Windows plus judicieuse, car correspondant plus aux besoins, plus économe et facilitant la migration des applications 32 bits.
Remarque : ces problèmes ne se posent que parce que le C est le C
(pas portable). Un language stricte et préis comme Ada, assigne au type pointer
(access) le type requis par le système et les type entiers sont le plus souvent définis par des intervals de valeurs
(et peuvent même recevoir des clauses de représentation, pour les interface de bas niveau)
Cela permet d'adresser plus de 4 Gigas de ram pour les applications, parfait pour l'image de synthèse, sinon en C un long double sera 'traiter' en une seule fois... théoriquement
le 64 bits consomme un peu plus de mémoire.
Un peu plus... ou nettement plus ...
Je doute un peu de l'utilité du passage au 64 bits, dont l'évidence n'est pas aussi flagrante que lors du passage du 16 bits au 32 bits
(mais je n'ai pas envie d'en discuter sur l'instant).
Et le problème, est comme souvent qu'il s'agira d'une migration forcée
(pour forcer un rachat de nouveau matériel ?)
Documents interessants à ce sujet :
Optimization of 64-bit programs
Ce que le 64 bits peut promettre et ne pas promettre.
L'intérêt de ce document, et qu'il n'est pas trop partisan
C variable types and declarations / Size
Bien que le C soit laxiste dans sa définition des type de base et surtout des types dérivés, il existent tout de même des obligations en ce qui concerne les relation entre les différents modificateurs des types de base. Ce document en fait un rappel.
[Libvir] Windows sizeof(long) != Linux sizeof(long)
Interessant témoignage dans une mailing liste, d'une personne venant de découvrir que le type long n'est pas le même sous Winows 64 que sous Linux 64.
64-Bit Programming Models: Why LP64?
Où l'on reparle de la différence entre IL32P64 vs I32LP64
