Discussion :

[luckyvae]

Bonjour,

Je suis en train de développer une application en C++, avec g++ comme compilateur, et je me suis rendu compte d'une chose curieuse à mes yeux avec une version 64 bits:
4 = __SIZEOF_INT__ != __SIZEOF_POINTER__ = 8
Je pensais que sous 64 bits, un entier serait codé sur 8 octets, mais apparemment les développeurs ont préféré garder la taille maximale des int identiques sur les systèmes 64 et 32 bits (ce qui est pas tip top de mon point de vue, mais bon...)
Du coup, je suis ennuyé car je transformais certains de mes pointeurs en entiers et ce n'est pas possible à moins de convertir les pointeurs en long, et les long en int.

Ma question est donc la suivante: existe-t'il un moyen pour que les int soient codés sur la même taille que les pointeurs?

Je sais que je pourrais définir mon propre type qui représenterait un entier de la même taille que les pointeurs, mais ça ferait pas très propre. Pour l'instant, la conversion pointeur->long->int est ce que j'ai trouvé de plus "propre" pour l'instant...

[Melem]

Ma question est donc la suivante: existe-t'il un moyen pour que les int soient codés sur la même taille que les pointeurs?

Utiliser un processeur 32 bits. Pour interchanger des int avec des adresses il faut être sûr que cela est sans danger pour la plateforme ciblée. Sur les proc (intel) 64 bits, interchanger des int avec des adresses n'a tout simplement (généralement) aucun sens car leurs tailles ne sont pas les mêmes. Quel est exactement ton but ? Et pour quel OS développes-tu ?

[nikko34]

hmm il faut que l'on te le dise, mais tu n'es pas sensé stocker des pointeurs dans des entier

[Laurent Gomila]

Je pensais que sous 64 bits, un entier serait codé sur 8 octets, mais apparemment les développeurs ont préféré garder la taille maximale des int identiques sur les systèmes 64 et 32 bits (ce qui est pas tip top de mon point de vue, mais bon...)

Si le type int avait une taille de 64 bits, il ne resterait plus assez de types entiers (char, short) pour représenter les tailles inférieures (8, 16, 32). Certes ce n'est pas une obligation, mais j'imagine mal un système (hormis les trucs exotiques) qui ne fournirait pas de type pour l'une de ces tailles.

Je sais que je pourrais définir mon propre type qui représenterait un entier de la même taille que les pointeurs, mais ça ferait pas très propre.

Pourquoi pas ? Ce serait justement la solution la plus propre, et surtout la seule qui soit correcte. D'ailleurs il existe de tels types (inptr_t par exemple -- je ne sais pas s'il est standard).

[Graffito]

Peut-etre 2 solutions en compilant avec

• gcc -m64 -o output64 ...
• gcc -m32 -o output32 ...

[luckyvae]

wow, pas mal de réponse, c'est chouette

Utiliser un processeur 32 bits. Pour interchanger des int avec des adresses il faut être sûr que cela est sans danger pour la plateforme ciblée. Sur les proc (intel) 64 bits, interchanger des int avec des adresses n'a tout simplement (généralement) aucun sens car leurs tailles ne sont pas les mêmes. Quel est exactement ton but ? Et pour quel OS développes-tu ?

Le soucis, c'est que je contrôle pas le choix des processeur utilisé par ceux qui vont utiliser mon application J'utilise cette astuce pour avoir "gratuitement" des hash code de mes classes: je transforme l'adresse de this en entier. Je sais que l'idée même d'utiliser des pointeurs comme hash code n'est pas la plus brillante qui soit car ceux-ci ne seront pas bien répartis, mais bon. Je développe sous linux, mais j'aimerai (tant que possible) que ce soit compilable par tout système possédant gcc.

hmm il faut que l'on te le dise, mais tu n'es pas sensé stocker des pointeurs dans des entier

je tient à vous rassurer, une fois transformer en int, ceux-ci ne sont plus jamais utilisés comme pointeurs

Si le type int avait une taille de 64 bits, il ne resterait plus assez de types entiers (char, short) pour représenter les tailles inférieures (8, 16, 32). Certes ce n'est pas une obligation, mais j'imagine mal un système (hormis les trucs exotiques) qui ne fournirait pas de type pour l'une de ces tailles.

de mon point de vue, je trouve que la taille des données devrait varier en fonction des architectures. Et les types de données de taille spécifiques devrait être définis comme des types de données spécifiques comme le fais opengl avec int32_t par exemple.

Je sais que je pourrais définir mon propre type qui représenterait un entier de la même taille que les pointeurs, mais ça ferait pas très propre.

Pourquoi pas ? Ce serait justement la solution la plus propre, et surtout la seule qui soit correcte. D'ailleurs il existe de tels types (inptr_t par exemple -- je ne sais pas s'il est standard).

Je préfèrerai garder le type 'int' car c'est ce que je veux obtenir, un entier. Définir un autre type nuirait à la lisibilité du code car dans certains cas les entiers sont des pointeurs 'castés', mais dans d'autres ce sont bel et bien des entiers.

Peut-etre 2 solutions en compilant avec

* gcc -m64 -o output64 ...
* gcc -m32 -o output32 ...

J'avais déjà vu ces options, mais le soucis c'est que:

The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture

Pour l'instant, la solution la plus 'propre' serait d'utiliser des long au lieu de int car les long ont une taille égale au pointeurs pour les deux architectures...