Discussion :

[nicolas66]

Bonjour !

Pour les besoins d'un projet, j'aimerai savoir comment je peux arriver à détecter si mon programme tourne sur une architecture 64-bits grâce à des flags préprocesseurs. Merci d'avance pour votre aide


Nico.

[roulious]

Sous gcc, on a __WORDIZE qui vaut 32 ou 64. Sous VC++, tu dois pouvoir te débrouiller avec la macro _WIN64. Pour les autres compilateurs, je ne sais pas, il n'y a rien de standard, à moins de jouer avec sizeof(void*).

[Laurent Gomila]

Un bon point de départ : http://predef.sourceforge.net (section "Architectures").

[nicolas66]

Merci pour le site mais je l'avais déjà visité hier (un site très utile au passage). Je ne suis pas sûr que ce soit suffisant de faire un truc de ce style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#if defined(__amd_64__) || defined(__ia64__)
        // alors on a affaire à un processeur 64 bits

En effet, je pense qu'il doit exister des processeurs powerpc ou mips en version 64 bits pour lesquels il n'existe apparement pas de flags (d'après le site). Et si c'était le cas, je devrai être obligé de trouver tous les flags des processeurs existants

[rigobert]

Et si c'était le cas, je devrai être obligé de trouver tous les flags des processeurs existants

Je pense que c'est plutôt une question de SDK que de processeur. C'est donc AMHA plutôt dans les docs des SDK qu'il faut fouiner.

De toute façon, lorsqu'on développe un projet portable on cherche généralement à savoir par quoi on est compilé (au niveau préprocesseur) de façon à éviter certains problèmes d'incompatibilité entre compilateurs, ou exploiter des spécificités.

La démarche pour le 32/64 bits est (ou devrait en tout cas) être la même...

[nicolas66]

Je pense que c'est plutôt une question de SDK que de processeur. C'est donc AMHA plutôt dans les docs des SDK qu'il faut fouiner.

Qu'est-ce que AMHA ?

[rigobert]

Qu'est-ce que AMHA ?

A Mon Humble Avis, traduction française de IMHO .

[nicolas66]

Ok pardon pour mon manque de culture rigobert . Pour revenir à mon problème, je n'ai pas vraiment compris pourquoi tu parlais de SDK.

Je précise que je souhaite détecter les architectures 64 bits pour pouvoir définir correctement des alias sur les entiers signés et non signés. Par exemple un entier non signé correspondrait à l'alias uint32 sur une architecture 32 bits tandis que le même entier correspondrait à l'alias uint64 sur une architecture 64 bits.

[Laurent Gomila]

Par exemple un entier non signé correspondrait à l'alias uint32 sur une architecture 32 bits tandis que le même entier correspondrait à l'alias uint64 sur une architecture 64 bits

Les types n'ont pas forcément les mêmes tailles d'une architecture 64 bits à une autre. Donc il faudra bien que tu trouves un moyen de gérer chacune individuellement.

[Médinoc]

En effet, sur Win64 par exemple, il me semble bien qu'un unsigned int reste un UINT32 : C'est surtout la taille des pointeurs et des size_t qui change.
Donc, je pense que le mieux est d'utiliser les types standard (uint32_t, etc.) pour tes alias, plutôt que de les redéfinir toi même...

[nicolas66]

En effet, sur Win64 par exemple, il me semble bien qu'un unsigned int reste un UINT32 : C'est surtout la taille des pointeurs et des size_t qui change.
Donc, je pense que le mieux est d'utiliser les types standard (uint32_t, etc.) pour tes alias, plutôt que de les redéfinir toi même...

Ah mince je pensais pourtant qu'un entier non signé sur une architecture 64 bits faisait 8 octets partout . Désolé d'avoir dit une bêtise.

Les alias dont tu parles sont-ils disponibles sur la plupart des compilateurs ? Si oui, quel est le fichier à inclure ?

[roulious]

Les alias dont tu parles sont-ils disponibles sur la plupart des compilateurs ? Si oui, quel est le fichier à inclure ?

Je ne crois pas qu'il y ait quelque chose de standard à ce niveau là. Par contre, boost fournit une solution, avec les [it]integer traits[/ti] : http://www.boost.org/libs/integer/integer.htm.

[koala01]

Ah mince je pensais pourtant qu'un entier non signé sur une architecture 64 bits faisait 8 octets partout . Désolé d'avoir dit une bêtise.

A vrai dire, la seule chose dont on puisse etre sur, car c'est la seule spécificité explicitement indiquée (du fait de l'héritage C)
char <= int <= long <= float <= double signe <= double non signé.

Ce que l'on peut aussi dire, c'est que si tu appelle sizeof(type) l'unité représente le char (qui pourrait tout aussi bien etre représenté sur 8 que sur 16 bits... voire meme plus)

Partant de là, il pourrait meme à l'extrème limite etre *théoriquement* possibe de trouver une architecture sur laquelles tous les types auraient la meme taille, vu que toutes les inégalités sont de type "plus petit ou égale au suivant"

Au passage, il me *semble* (pour ce que je m'en souvient de l'avoir entendu au cours d'une discution) que les mainframe actuels sont également en architecture 64 bits

[Laurent Gomila]

Je précise que je souhaite détecter les architectures 64 bits pour pouvoir définir correctement des alias sur les entiers signés et non signés. Par exemple un entier non signé correspondrait à l'alias uint32 sur une architecture 32 bits tandis que le même entier correspondrait à l'alias uint64 sur une architecture 64 bits

En général on cherche à faire l'inverse : on cherche le bon type pour une taille souhaitée. Si tu veux les types d'entiers qui correspondent le mieux à la plateforme, alors ce sera juste int / unsigned int.