iOS 7 pour le 18 septembre !
Draken
Membre
C'est Timy qui viens de le dire !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est surtout Phil qui a dit que le 5C serait sans Android
Si vous pensiez avoir presque fini de porter votre app sur iOS 7, maintenant il va falloir également la passer en 64 bits...
On peut envoyer dorénavant nos apps pour iOS 7.
Mais uniquement-elles ? Ou on peut encore envoyer des binaires iOS 6 ?
Ca n'a pris que 2h à l'équipe d'Infinity Blade 3 pour porter sur 64 bits. Et ce sont des jeux qui utilisent OpenGLES et des trucs en C bas niveau (donc potentiellement des structures qui sont dépendantes de l'endianness).
En pratique pour la plupart des applications il n'y a strictement rien à changer dans le code pour que la compilation en 64 bits fonctionne. Et au pire Xcode5 active le warning si tu fais des lossy conversions de 64 bits vers 32 bits (mais comme jusqu'à présent tu as codé pour du 32 bits de toute façon, tu n'utilisais pas encore des types 64 bits donc y'a peu de chances que tu aies le cas pour ton portage !)
euhhh.... Ca m'inquiéte là ... Y a un truc spécial sur la GM d'XCode 5 pour le 64 bits ?
En terme de code à retoucher, la compilation en 64 bits d'un code écrit pour du 32 bits normalement c'est rien du tout à toucher.
A part si tu écris du code assembleur, ou que tu fais des opérations très bas niveau sur les régistres ou des choses qui prennent en compte la représentation interne de tes données (genre des trucs tordus du style tester le bit 31 d'un entier pour savoir s'il est positif ou négatif parce que tu assumes que ton entier est sur 32 bits), t'as aucun souci à te faire.
ok, me voilà rassuré. Je teste jamais le bit 31 d'un entier... Je considère ça comme un sacrilège.
:-)
Mince, je dois revoir toute mon appli
Je plaisante xd
Quoi que ça me rappelle mes cours de BTS tout ça...
Je vous trouve bien optimiste. >:D
Enfin, si vous êtes confiant dans tout votre code et les bibliothèques que vous utilisez, tant mieux !
À mon avis, les soucis surgissent quand on relit des fichiers binaires; c'est un problème similaire à l'endianness.
Les soucis surgissent si on fait du C à l'ancienne ou salement.
En utilisant des structures qu'on échange avec d'autres plateformes, en stockant des pointeurs dans des int.
Le NSInteger passe en 8 octets alors que l'int reste à 4 octets. En soi je ne pense pas que cela puisse poser de problème si on n'utilise pas les overflows.
Plus vicieux, le CGFloat passe en 8 octets et le float est à 4 octets. Je suppose que cela peut changer les précisions sur les calculs en virgules flottantes. Donc si on teste des égalités entre float et CGFloat, je pense que cela doit pouvoir poser des problèmes. (Mais c'est déjà dangereux à la base).
Vu que ce problème potentiel qui date du C est dû aux précisions des représentations IEEE754 des nombres décimaux, il existe potentiellement déjà en C 32 bits et je pense que si le compilateur ne compensait pas déjà cela tout seul on aurait déjà eu le souci sur de l'ObjC 32 bits (même si certes comme tu le soulignes du coup en 64 bits avec meilleure précision le risque serait alors plus grand car l'erreur de précision CGFLOAT_EPS plus petit) alors qu'en pratique je n'ai jamais eu à utiliser cette protection depuis que j'ai abandonné le C, donc ça serait à vérifier...