CGFloat: quand ne pas les utiliser?
colas_
Membre
Bonjour,
J'ai pris le réflexe d'utiliser les CGFloat pour tout ce qui est graphique (frame, etc.)
Mais, lorsque je dois manipuler des nombre à virgules dans mon modèle, je mets plutôt des float. D'ailleurs, coredata ne propose pas CGFloat.
Me conseillez-vous plutôt de toujours utiliser des CGFloat ? Par exemple, je n'utilise jamais int mais toujours NSUInteger ou NSInteger.
Quelles sont vos pratiques pour les float ?
Merci !
Colas
PS : Je sais vaguement que cela a avoir avec 32/64 bits mais j'ai l'impression que le 32bits est fini.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
CGFloat est un type "indépendant" du format. Il est aujourd'hui essentiellement 64 bits, mais il peut très bien passer à du 128 bits si les processeurs le permettent un jour et si Apple le juge nécessaire, et sur un processeur 32 bits, CGFloat est 32 bits.
Donc, cela peut avoir un impact si une rétrocompatibilité est requise, ou si on doit formaliser précisément des données. Par exemple si des CGFloat sont aujourd'hui stockées (en 64 bits) dans un fichier, et qu'il s'agit de lire ce fichier un jour, lorsque le format sera 128 bits.
float, double et long double (80 bits) permettent de savoir exactement ce qu'on est en train de manipuler et d'éviter les erreurs.
Par ailleurs, le 32 bits n'est pas fini dans le domaine du calcul parallèle (GPGPU) par exemple, ou les GPU sont encore trop lents en double.
Peut-être ça à garder en tête.
J'ai aussi tendance à utiliser des CGFloat quand ce sont des positions graphiques.
Et de plus en plus souvent, j'utiliser des NS(U)Integer, surtout sur des retours de méthodes qui renvoient ça.
Le passage en 64 bits le signalait (sur cast int non explicit), et plutôt que de caster tout bêtement en int...
Toute manipulation des nombres (calculs, arrondis,...) : NSDecimalNumber.
Autant se tirer une balle dans le pied droit. Toi tu fais pas souvent du calcul matriciel.
klog a très bien résumé la chose. D'expérience personnelle côté CPU, des calculs intensifs sont toujours plus performants en 32bits qu'en 64 donc je reste systématiquement en float quand besoin de précision après la virgule.
Pour le gain que promettait à une époque Apple lors du passage en 64bits, comme d'habitude, il fallait lire entre les lignes. Dans les fait seuls des calculs full 64bits sont légèrement améliorés mais cela reste largement en deçà de l'usage des floats 32 bits.
Il faut vraiment avoir besoin d'une précision "scientifique" et/ou de manipuler des valeurs extrêmes pour que le passage en 64bits soit réellement justifié.
Merci pour vos réponses.
En fait, ma question float vs CGFloat, ce n'était pas par rapport à la performance mais c'était plus par rapport aux éventuels futurs problèmes de compatibilité. @Larme : j'avais le message que tu as linké en tête.
J'ai pris le réflexe de garder CGFloat pour le graphisme juste car c'est préfixé CG (core graphics). Si ça avait NSFloat, hé bien, je l'aurai utilisé partout ;-)
Le calcul vectoriel se fait également en 32 bits et on obtient là aussi de meilleurs performances qu'en double précision.
Les types d'Apple sont dangereux en terme d'interopérabilité pour les raisons expliquées par klog.
Y a-t-il simplement un intérêt à ce que CGFloat soit en 32 bits ou 64 bits selon l'architecture de la machine ? Je n'ai jamais compris pour quelle raison Apple a fait ça.
Oui en terme de performance c'est sure que les float sont plus rapides, mais adieux la précision.
Après tu peux aussi utiliser NSDecimal si tu cherches plus de performances que le NSDecimalNumber et faire ses calculs en base décimale.
float : calculs plus rapides.
NSDecimalNaumber : calculs plus précis
@mala Tu utiliseras des float pour une application boursière ou bancaire ?
Pour une application boursière ou bancaire? Heu et le type double tu en fais quoi???