redangel (./560) :Ça n'a rien de "pas propre". La solution d'apple est à mon humble avis complètement conne. Si ton programme tournait parfaitement avec des entiers limités sur 32 bits (ce qui est le cas de l'API Cocoa), il n'y a aucune raison d'utiliser des champs qui prennent deux fois plus de place. (Surtout que parfois ça va être pour y stocker des valeurs d'enum qui n'occupent que quelques bits en réalité…GoldenCrystal (./552) :Ca a au moins le mérite d'être propre.
Chez Apple -> On passe *tout* en 32 bits. (Int32 -> Int64; Float32 -> Float64 )GoldenCrystal (./552) :Pas besoin... sauf... : pas propre
le reste n'a pas besoin de changer. (Sauf besoin explicite)
)La décision sur les float est encore plus irrationnelle. Cela n'a aucun sens d'utiliser des float32 en 32 bits et des float64 en 64 bits. La différence entre float et double, c'est une histoire de précision, pas d'ABI… Pourtant ils l'ont fait, et ça n'a là encore aucun intérêt. (Même histoire qu'avant, si ça tournait nickel avec des float32, c'était pas la peine d'y mettre des float64…)
Au final, si tu utilises des types de l'API OSX comme NSInteger ou CGFloat, ben tes structures mémoires vont prendre exactement le double de mémoire par rapport à la version 32 bits et ça n'apportera rien de spécial, hors cas particulier genre "je met un pointeur dans un entier".
Pire encore, tes applications auront peut-être un comportement différent entre x86 et x64… et ARM… Concernant les entier, y'a aussi le choix de l'ABI native LP64 (pour le compilateur C/C++/Objective-C) qui fait qu'un long est 32 bits sur une plateforme 32 bits et 64 bits sur une plateforme 64 bits. C'est le même choix que celui fait par Linux, que je trouve con aussi, mais à la limite, dans ce cas le problème vient du langage C qui à la base ne définit pas des types de taille stricte… Et ça ne t'affecte que si tu utilises explicitement des long (32 bits sur CPU x86 32 bits… En fait j'ai jamais trouvé ça logique à la base, mais bon
) donc c'est pas aussi gênant que le choix complètement crétin de Apple../567 > Certainement parce que ça demandait de nouveaux développement quelle que soit la solution choisie, pour une audience extrêmement réduite. (i.e. l'effort n'en valait pas la peine) Après tout, on est quand même loin d'être nombreux à avoir besoin d'une telle fonction. (Personnellement, je ne connais personne dans ce cas dans mon entourage proche ou moins proche. Et si je veux lancer un vieux jeux, ben j'utiliserai DOSBox, et en prime ça tournera sous OSX ou Linux
)D'autre part, ça leur permet d'assainir leur système. On peut facilement envisager que dans une hypothétique future version de Windows (Windows 9 ?) la seule architecture disponible sera 64 bits, et toutes les applications tourneront en mode WOW64 ou bien en mode 64 bits natif… Dans ce cas ils pourront purement et simplement dégager la branche de compatibilité 16 bits qui doit quand même leur peser assez lourd… (Je suis certain qu'ils seront ravis de s'en débarrasser
)
)