Unterschiede von Appmethod C++ für 64-Bit-Windows

Aus Appmethod Topics
Wechseln zu: Navigation, Suche

Nach oben zu Appmethod C++-Anwendungsentwicklung für 64-Bit-Windows


Einen Überblick über die Unterschiede zwischen BCC64 und seinem unmittelbaren Vorgänger BCC32 finden Sie unter Unterschiede zwischen bcc64 und C++-Compilern der vorherigen Generation. BCC64 ist der neueste Compiler in einer langen Reihe von Compilern, die mit der Geschichte der C/C++-Entwicklung seit DOS und 16-Bit-Windows verflochten sind.

Informationen über die auszuführenden Schritte zum Portieren von vorhandenen 32-Bit-C++-Projekten nach 64-Bit-Windows finden Sie unter Upgrade von vorhandenen C++-Projekten nach 64-Bit-Windows.

Unterschiede zwischen 32-Bit-Windows- und 64-Bit-Windows-Anwendungen

Im Internet wird der Wechsel zur 64-Bit-Entwicklung ausführlich behandelt, insbesondere in Bezug auf C++ und Windows. Weitere Informationen finden Sie in den folgenden Themen:

Auf zwei grundlegende Konzepte wird in diesem Thema besonders eingegangen.

size_t und unsigned

size_t ist als vorzeichenloser Integraltyp definiert, der an malloc und an das Ergebnis von sizeof mit genügend Bits übergeben wird, um die Größe des größtmöglichen Objekts im Speicher/Datenmodell darzustellen. In Win32 und Win64 ist das die Größe eines Zeigers. (Die modernen Windows-Speichermodelle sind linear. Im Gegensatz dazu waren Zeiger in dem segmentierten "Large"-Speichermodell von DOS 32 Bit groß, und das größte Objekt umfasste 64 KB. Daher konnte size_t 16 Bit sein.)

Im "ILP32"-Datenmodell von Win32 sind int (und long) und Zeiger 32 Bit groß. Sie könnten unsigned int anstelle von size_t verwenden, es wäre allerdings nicht portierbar.

Win64 ist ein "LLP64"-Datenmodell: long long und Zeiger sind 64 Bit groß und int (und long) sind weiterhin 32 Bit groß. Deshalb müssen Sie size_t verwenden.

_WIN32 ist für Win64 definiert

_WIN32 ist (als Integerzahl 1) für Win32- und Win64-Ziele definiert. Damit wird ermöglicht, dass Programme für (moderne) Windows-Versionen sowie für andere Plattformen entwickelt werden können.

_WIN64 ist nur für Win64-Ziele definiert; da _WIN32 auch definiert ist, sollten Sie zuerst _WIN64 etwa folgendermaßen überprüfen:

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

OLE_HANDLE hat auch unter 64-Bit-Windows den Typ 32-Bit-Long

Unter Win64 wurde die Größe von HANDLE-Typen in 64 Bit geändert – mit Ausnahme von OLE_HANDLE, das jetzt auch in Win64 den Typ 32-Bit-Long ist. Das bedeutet, dass Sie Code ändern müssen, in dem davon ausgegangen wird, dass OLE_HANDLE und andere HANDLE-Typen austauschbar sind. Siehe auch http://stackoverflow.com/questions/401812/what-is-the-proper-way-to-cast-from-an-ole-handle-to-an-hicon.

Compiler-Unterschiede

BCC64 basiert jetzt auf dem Clang-Compiler-Frontend. Siehe:

#include windows.h

C++-Anwendungen für 64-Bit-Windows sollten immer folgende Include-Anweisung enthalten:

 #include <windows.h>

Für BCC32 ist das Einbeziehen von windows.h nicht erforderlich, aber BCC64 erfordert windows.h und ist wie alle anderen Clang-basierten C++-Compiler strikter in Bezug auf #include-Anweisungen.

Erstellung von 64-Bit-Packages wird jetzt unterstützt

BCC64 erstellt ab dem 1.14-Release 64-Bit-Windows-Packages (.bpl-Dateien). Sie können auch statisch mit einem 64-Bit-Windows-Package linken und Packages mit Appmethod C++ für 64-Bit-Windows verwenden.

Beachten Sie bitte, dass Appmethod C++ keine DYLIBS für den Mac oder Packages für die iOS- und Android-Plattformen erzeugt. Für diese Plattformen können statische Bibliotheken verwendet werden.

Unterschiede zwischen Win32- und Win64-Packages

Der Compiler exportiert für Win64 Codeelemente, die mit PACKAGE gekennzeichnet sind, wenn sie in der aktuellen Übersetzungs-Unit definiert sind. Bei Klassen wird die Klasse exportiert, wenn ein Nicht-Member definiert ist. Wenn keine Definition vorhanden ist, behandelt der Compiler das Codeelement als importiert. Dieses Verhalten unterscheidet sich vom Verhalten unter Win32.

Sie müssen PACKAGE für Win32 und Win64 verwenden, aber Win64 exportiert nur, wenn eine Definition vorhanden ist. Diese Anforderung gilt für Variablen, Funktionen und Klassen, die für den Verwender des Package bereitgestellt werden sollen.

Beispiel:

 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);

Allgemeine Informationen finden Sie unter Erzeugen von statischen Packages.

Anforderungen für Win64-Packages

  • Um eine Komponentenklasse aus einem Package zu exportieren, muss mindestens ein Nicht-Inline-Member für jede Komponente vorhanden sein (der Experte Datei > Neue Komponente führt dies für Sie durch).
  • Wenn Sie zuvor das Package-Ausgabeverzeichnis für die Erstellung eines Win32-Package eingestellt haben, müssen Sie auf der Seite >Tools > Optionen > Umgebungsoptionen > C++-Optionen > Pfade und Verzeichnisse (C++) den Pfad für Ihr Win64-Projekt ändern, damit Ihr Win32-Package nicht überschrieben wird. Wenn Sie das Package-Ausgabeverzeichnis überschreiben, können Sie überprüfen, ob das Verzeichnis für endgültige Ausgabe unter Projekt > Optionen > C++ (Gemeinsame Optionen) korrekt festgelegt ist. Das heißt, dass das Verzeichnis für endgültige Ausgabe für Win32 und Win64 unterschiedlich sein muss.

Debugger-Funktionen

Siehe Debuggen von Appmethod C++-Anwendungen für 64-Bit-Windows.

Siehe auch