Les nouveaux types de données sous AmigaOS 4

Un article de GuruMed.

Les types de données sous AmigaOS 4

par Alex

OS Applicables

Par convention AmigaOS a toujours utilisé des types de donnés personnalisés pour ces prototypes (ULONG, WORD, etc.), le problème est que certain de ces types de données ont été créés pour les processeurs 68k et que leur taille réelle avait été calibrée en fonction d'eux. Ainsi un WORD (un mot processeur) est stocké sur 16 bits, un LONG sur 32 bits... Or ce n'est pas forcément le cas sur toutes les architectures.

Pour pallier à cela, (et comme sur de nombreux autres systèmes d'exploitation), il a été créé des types dont la taille est explicite et ne changera pas quelque soit l'architecture. Ces types sont dorénavant à privilégier dans tous les nouveaux codes, en voici la liste :

int8	uint8
int16	uint16
int32	uint32
int64	uint64

Pour les autres types de données, le problème n'existe pas réellement : un CHAR correspond toujours au char de l'architecture, un DOUBLE au double, etc.

Je rappelle toutefois que si par un concours de circonstance UBYTE * et STRPTR étaient interchangeable dans les versions antérieures de l'OS, ce n'est plus le cas maintenant et mieux vaut déclarer vos chaînes de caractères avec le bon type si vous voulez éviter quelques tonnes de warning à la compilation, vous aurez été prévenus...

Dans le même esprit si auparavant NULL pouvait être employé pour mettre une valeur entière à 0, ce n'est plus le cas maintenant puisque sa définition est (comme elle aurait toujours due l'être) faite pour que ce soit un pointeur. Cela risque de vous causer pas mal de warnings si vous utilisez NULL pour initialiser des variables autres que des pointeurs. D'ailleurs si vous programmez avec la DOS.library vous manipulerez certainement des BPTR attention maintenant une valeur spéciale a été créée pour faire office de valeur nulle, j'ai nommée ZERO, si vous tentez d'utiliser NULL vous obtiendrez également des warnings de la part de votre compilateur.

Tout ceci n'est pas (que) fait pour vous embêter avec les bonnes options de compilation (warning au maximum et interdiction de compiler s'il y a un warning) cela vous permet de déceler beaucoup d'erreurs de programmation au moment de la compilation et éviter donc ainsi quelques bogues dit « d'inattention ».