Discussion :

[camboui]

Je recompile des prgs en 64 bits sans trop de soucis fonctionnel, et en apparence sans erreur d'éxécution.
Par contre, le nombre de warning est décourageant.

J'utilise visual studio (sous Windows).
unsigned et DWORD restent des 32 bits, et size_t (et SIZE_T) deviennent des 64 bits. Cas très fréquent de warning, des variables ou membres de structure de type unsigned auxquels on affecte des valeurs provenant de la STL (exemple, size() et length() qui sont des size_t).
Une solution serait de user des static_cast<unsigned>, mais après en avoir tapé 328 je me dis qu'il y aura un soucis un jour... Sans compter la lisibilité du code.
Une autre solution serait de remplacer tous les unsigned par des size_t. C'est facile et peut-être sécurisant, mais sans doute pas toujours opportun. Parfois aussi le warning est alors déplacé ailleurs.

size_t ou unsigned ?
Revoir tout le code, oui mais en faisant attention à quoi ?
Y'a-t-il une "recette" ?
Merci.

[Niark13]

Salut,

Tu as de la chance si l'appli que l'on te demande de porter ne caste pas des pointeurs vers des longs (et vice-versa). J'ai eu à intervenir sur une horreur de la sorte (qui en plus est multi-plateforme, donc les longs ne faisaient pas forcément la même taille partout).

Pour ma part, je préfère utiliser size_t à unsigned ou à DWORD dans tout le code qui n'est pas spécifique à une plateforme. Size_t rajoute une valeur sémantique (on va stocker une taille ou un nombre d'élément) qu'il n'y a pas dans unsigned. Et size_t est justement fait pour s'adapter aux limites de l'architecture. À moins d'en stocker de gros tableaux, le surpoids lié à l'utilisation de size_t est négligeable.

Pour le code spécifique plateforme (genre UI), un static_cast.

[mala92]

salut,

les joies de la migration, à ce jeu j'ai découvert que le int faisait 4 octets quelque soit le plate-forme (tout le contraire de ce qu'on apprend à l'école).
par contre le "long", 4 octets en 32bit et 8 octets 64bit.

mieux vaut travailler avec les types de base.

[dragonjoker59]

long est malheureusement un type de base...
J'évite de l'utiliser.
Au niveau de visual studio, tu peux compiler un code 32 bits en activant les warnings qui sont liés à la compilation 64 bits en ajoutant l'option -Wp64 à la ligne de commande, c'est assez pratique.

[Bousk]

Si la taille des données importe vraiment, je ne comprends pas que vous n'ayiez pas vos propres int32, int64, etc.
Et là, la migration est triviale.

[Meseira]

Pour assurer la portabilité, il est aussi possible d'utiliser les types d'entiers déclarés dans cstdint (C++11). Pour les entiers non signés, on y trouve, par exemple, uint32_t et uint64_t :
http://www.cplusplus.com/reference/clibrary/cstdint/

[mala92]

long est malheureusement un type de base...
J'évite de l'utiliser.

Tout à fait d'accord.
Quand tu utilises long tu sais à quoi t'attendre, par contre DWORD, je ne sais pas si c'est un int ou un long. (bon je viens de faire F12 dans VS, j'ai tout faux, c'est unsigned long)

Y'a-t-il une "recette" ?

Celle de Bousk me parait pas mal!

[ternel]

C++ ne donne pas la longueur des types de bases, seulement un rapport: char ≤ short ≤ int ≤ long ≤ long long
un int est censé s'aligner sur la taille du mot mémoire.