typedef struct....
-
Hi,
das Win32API definiert folgendes....
#define DECLARE_HANDLE(n) typedef struct n##__{int i;}*n
also sowas wie...
typedef struct puups__{int i;}*puups;
Wenn ich jetzt
int i = 4444; puups pppp; ppp = (puups) i; std::cout << "pppp: " << pppp << std::endl; std::cout << "Addresse von pppp: " << &pppp << std::endl;
Dann ergibt die erste Ausgabe: ppp: 0x115c.
Das ist ja hexadezimal 4444.Wird durch diese struct ... alias ein Zeiger auf einen Int definiert?
Also sowas...
typedef int* IPTR; ... IPTR iptr = (IPTR) i;
Weshalb wird das im Win API über die Struktur gemacht? Ist das nicht etwas umständlich für eine Zeigerdefinition oder bin ich da völlig aus der Kurve?
-
Dieser Thread wurde von Moderator/in pumuckl aus dem Forum C++ (auch C++0x und C++11) in das Forum WinAPI verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Es wird über eine Struktur gemacht, damitman Handles nicht wahlfrei vertauschen kann.
Jeder Handle-Typ wird dadurch zu einem eineindeutigen (aber undefinierten) Datentyp...
Würdest du alles auf einen INT* zurückführen könntest Du die Handles unterienander vertauschen. Also ein GDI Handle für ein Window Handle benutzen.
-
Martin Richter schrieb:
Jeder Handle-Typ wird dadurch zu einem eineindeutigen (aber undefinierten) Datentyp...
Wieso undefiniert? Die sind nichtmal anonym.
-
Undefiniert, weil Du nicht weisst, was sich dahinter verbirgt (außer ein "int*"; was aber intern nicht dahinter steht
-
Das ist das Prinzip eines Handles, das hättest du genauso bei Typedefs auf int (oder int direkt). Mit dieser Technik, das eigentliche Handle in eine Struktur einzupacken, hat das nichts zu tun.
-
Übersetze mal den Folgenden Code, dann wird es klar, warum man ein "struct" braucht!
#include <windows.h> #include <tchar.h> typedef int ha_1; typedef int ha_2; typedef int *hb_1; typedef int *hb_2; typedef struct {int i;} *hc_1; typedef struct {int i;} *hc_2; int _tmain() { ha_1 a1 = (ha_1) 1; ha_2 a2 = (ha_2) 2; a1 = a2; // no warning or error hb_1 b1 = (hb_1) 3; hb_2 b2 = (hb_2) 4; b1 = b2; // no warning or error hc_1 c1 = (hc_1) 3; hc_2 c2 = (hc_2) 4; c1 = c2; // error }
-
Was soll das denn jetzt? Du musst mir keine C-Basics erklären. Es geht um das "undefiniert".
-
Ich glaub mit "undefiniert" meinte er eigentlich "inkomplett"
-
Ich verstehe vermutlich weder Euer Problem noch EUre Frage... deswegen sag ich jetzt nix mehr...
-
Hi,
ja danke Jochen und dem Rest... Die beiden Moderatoren haben mich auf dem richtigen Weg gebracht, die anderen Beiträge waren dann "Gedankenschubser" aber nicht weniger hilfreich. Jo, mal gaaanz von Anfang an.
Hätte Microsoft nur...
typedef int HICON; typedef int HFONT; typedef int HCURSOR; ... HICON hIcon; HFONT hFont; HCURSOR hCursor;
dann wären HCURSOR,.. integer, also auf den 32-Bit Maschinen 4-Byte groß.
Sie sind eindeutige Identifikatoren für Resourcen, die weder dem Programmierer noch "C++ - Klassen" gehoren, sondern dem Kernel. Um mit Ihnen zu arbeiten benötigt man einen eindeutige Zahl, die füe eine der Resourcen steht.
Ok. nur die Int's wären da schon ok, aber sie sind für den Programmierer nicht eindeutig. Da jaHIcon = hFont;
funzt. Für den Compiler richtig, da beide Int. Aber für die unterschiedlichen Resourcen werden deren Unterschidlichkeit nicht wirklich "ausgedrückt". Gleiches gilt natürlich auch für die Zeiger. Jede Zeigervariable kann Adressen als Wert erhalten, sind diese vom gleichen Typ, dann kann man sie ohne weiteres zuweisen.
Wenn man daher dann
... typedef struct HICON__{int i;}*HICON; typedef struct HFONT__{int i;}*HFONT; ...
dann sind HICON und HFONT 4 Byte groß and das "i" muss man nicht ran. Sie nehmen die Resourcenidentifikatoren auf und sind, weil die struct's nicht zuweisungskompatibel, schön voneinander zu unterscheiden.
uff.
Na mal sehen, ich glaube heute ist Grillabend, ich faxe dann mal ein paar Würstchen.