Différences C++ Builder Windows 64 bits

De RAD Studio
Aller à : navigation, rechercher

Remonter à Développement d'applications C++ Builder Windows 64 bits


Voir Différences entre les compilateurs bcc64 et les compilateurs C++ de précédente génération pour une présentation des différences entre BCC64 et son prédécesseur immédiat, BCC32. BCC64 est le dernier d'une longue lignée de compilateurs indissociable de l'histoire du développement C/C++ depuis DOS et Windows 16 bits.

Pour les étapes particulières relatives à la migration de vos projets C++ 32 bits vers Windows 64 bits, voir Mise à niveau des projets C++ existants vers Windows 64 bits.

Différences entre les applications Windows 32 bits et Windows 64 bits

La migration vers un développement 64 bits est un sujet qui a été largement couvert sur Internet, tout particulièrement en ce qui concerne C++ et Windows. Pour plus d'informations, voir les rubriques suivantes :

L'accent est mis sur deux concepts élémentaires.

size_t comparé à unsigned

size_t est défini comme un type intégral non signé, passé à malloc et le résultat de sizeof, avec suffisamment de bits pour représenter la taille de l'objet le plus volumineux possible dans le modèle mémoire/données. Dans Win32 et Win64, c'est la même taille qu'un pointeur. (Ces modèles mémoire Windows modernes sont linéaires. En revanche, dans le modèle mémoire Large segmenté de DOS, les pointeurs étaient des pointeurs 32 bits, et l'objet le plus volumineux faisait 64 Ko. Ainsi size_t pouvait être 16 bits.)

Dans le modèle de données "ILP32" de Win32, int (et long) et les pointeurs ont une longueur de 32 bits. Vous pouvez utiliser unsigned int à la place de size_t, même s'il n'est pas portable.

Win64 est un modèle de données "LLP64" : long long et les pointeurs ont une longueur de 64 bits, alors que int et long ont toujours une longueur de 32 bits. Par conséquent, vous devez utiliser size_t.

_WIN32 est défini pour Win64

_WIN32 est défini (comme l'entier 1) pour les cibles Win32 et Win64. Cela permet aux programmes de cibler les versions récentes de Windows en général parmi d'autres plates-formes.

_WIN64 est défini uniquement pour les cibles Win64. Comme _WIN32 est aussi défini, vérifiez d'abord _WIN64 de la façon suivante :

#if _WIN64
  // 64-bit Windows
#elif _WIN32
  // 32-bit Windows
#elif __APPLE__
  // macOS
#else
  #error Not a supported platform
#endif

OLE_HANDLE a une longueur de 32 bits même sur Windows 64 bits

Sur Win64, la taille des types HANDLE est passée à 64 bits, sauf pour OLE_HANDLE qui a maintenant une longueur de 32 bits même sur Win64. Ce qui signifie que vous devez changer tout code qui supposait que les types OLE_HANDLE étaient interchangeables avec d'autres types. Voir aussi http://stackoverflow.com/questions/401812/what-is-the-proper-way-to-cast-from-an-ole-handle-to-an-hicon (EN).

Différences entre les compilateurs

BCC64 est basé sur le frontal du compilateur Clang. Voir :

#include windows.h

Vos applications C++ Windows 64 bits devraient toujours contenir :

#include <windows.h>

Avec BCC32, l'inclusion de windows.h n'est pas obligatoire, mais BCC64 requiert windows.h et comme les autres compilateurs C++ améliorés par Clang, il est plus strict concernant les #includes.

La production de packages 64 bits est désormais prise en charge

BCC64 produit des packages Windows 64 bits (fichiers .bpl) à compter de la release XE6. Vous pouvez également lier statiquement un package Windows 64 bits et exploiter des packages en utilisant C++Builder Windows 64 bits.

Notez que C++Builder ne produit pas de dylibs pour le Mac, ou de packages pour les plates-formes iOS et Android. Pour ces plates-formes, il est possible d'utiliser des bibliothèques statiques.

Différences entre les packages Win32 et Win64

Pour Win64, le compilateur exporte les éléments de code marqués comme PACKAGE s'ils sont définis dans l'unité de traduction en cours. Pour les classes, si un non membre est défini, la classe est exportée. Si aucune définition n'est vue, le compilateur traite l'élément de code tel qu'il a été importé. Ce comportement est différent de celui de Win32.

Vous devez utiliser PACKAGE pour Win32 et Win64, mais Win64 n'effectue l'exportation que si une définition est présente. Cette exigence s'applique aux variables, fonctions et classes qui sont censées être exposées aux consommateurs du package.

Exemple :

class PACKAGE TTest : public System::TObject {
private:
  int FProp;
  __property int Prop = {read=FProp, write=FProp};
public:
  __fastcall TTest(void);
  __fastcall virtual ~TTest(void);
};
PACKAGE bool GoodieFlag;
PACKAGE void __fastcall SuperFunc(const System::UnicodeString S);

Pour des informations générales, voir Construction de packages.

Exigences relatives aux packages Win64

  • Pour exporter une classe de composant à partir d'un package, vous devez vérifier qu'il existe au moins un membre non inline pour chaque composant (l'expert Fichier > Nouveau composant le fait pour vous).
  • Si vous avez précédemment défini l'option Répertoire de sortie des packages pour produire un package Win32, vous devez changer le chemin d'accès à votre projet Win64 sur la page Outils > Options > Options d'environnement > Options C++ > Chemins et répertoires (C++) pour que votre package Win32 ne soit pas écrasé. Si vous écrasez le répertoire de sortie des packages, vous pouvez vérifier que le répertoire de sortie final est correctement défini dans Projet > Options > C++ (options partagées). C'est-à-dire que le répertoire de sortie final doit être différent pour Win32 et Win64.

Fonctionnalités du débogueur

Voir Débogage des applications C++ Builder Windows 64 bits.

Voir aussi