C/C++ Forum :: Frage zu Doppelzeiger (IO-Funktion + GetQueuedCompletionStatus)

Unregistrierter

Hi!

Irgendwie verschiebt sich der Pointer auf overlapped um 4, wenn ich ihn bekomme.

Info:
AcceptEx: http://msdn.microsoft.com/en-us/library/ms737524
GetQueuedCompletionStatus: http://msdn.microsoft.com/en-us/library/aa364986
(Man übergibt AcceptEx eine Adresse, und bekommt sie dann bei GetQueuedCompletionStatus wieder. Bei mir allerdings manchmal 4 Bytes verschoben)

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	1 2 3 4 5 6 7 8 9 10 11 12	struct Context : public OVERLAPPED { // ... }; // ... Context* newContext = new Context; // ... AcceptEx(..., (OVERLAPPED*)newContext );

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	struct Context : public OVERLAPPED { // ... }; // ... Context* newContext = new Context; // ... AcceptEx(..., (OVERLAPPED*)newContext );

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	struct Context : public OVERLAPPED { // ... }; // ... Context* newContext = new Context; // ... AcceptEx(..., (OVERLAPPED*)newContext );

Ok gut, nun bekomme ich eine completion.

So gehts:

C/C++ Code:
OVERLAPPED* overlapped; GetQueuedCompletionStatus(..., (OVERLAPPED*)&overlapped); Context context = (Context)overlapped; // Ok, context == newContext*

C/C++ Code:
OVERLAPPED* overlapped; GetQueuedCompletionStatus(..., (OVERLAPPED*)&overlapped); Context context = (Context)overlapped; // Ok, context == newContext*

C/C++ Code:
OVERLAPPED* overlapped; GetQueuedCompletionStatus(..., (OVERLAPPED*)&overlapped); Context context = (Context)overlapped; // Ok, context == newContext*

Und so gehts nicht, weil dann context plötzlich 4 Bytes weiter zeigt, als der dem AcceptEx übergebene Context.

C/C++ Code:
Context* context GetQueuedCompletionStatus(..., (OVERLAPPED*)&context); // Nicht Ok, context == newContext + 4 (???)*

C/C++ Code:
Context* context GetQueuedCompletionStatus(..., (OVERLAPPED*)&context); // Nicht Ok, context == newContext + 4 (???)*

C/C++ Code:
Context* context GetQueuedCompletionStatus(..., (OVERLAPPED*)&context); // Nicht Ok, context == newContext + 4 (???)*

Warum ist das so? Zeiger ist doch gleich Zeiger?

THX!

Unregistrierter

hast du virtuelle Methoden in deinem Context?

Unregistrierter

Danke für den Tip, habs grad mit nem Minimalbeispiel versucht. Liegt tatsächlich am virtuellen Destruktor von Context.

Bin aber viel zu eingerostet in C++, um mir erklären zu können, warum...

Unregistrierter

Unregistrierter

Nimm static_cast statt C-Casts!

Unregistrierter

Bringt nix.

Unregistrierter

Need Input

theta Mitglied 12:02:12 16.01.2011 Titel:

--- hier stand blödsinn ----

Zeiger ist nicht gleich Zeiger - Zeiger auf abgeleitete Klass können anders sein als Zeiger auf Basis Klassen - man denke da nur mal an die Mehrfachvererbung.

hustbaer Mitglied 17:05:20 16.01.2011 Titel:

Ich verwende ähnlichen Code öfters, funktioniert wunderbar.
Funktioniert bloss nicht, wenn man nicht korrekt castet.
Wenn du z.B. von "Context" zu "void*" castest, und dann von "void*" zu "OVERLAPPED*", dann wird das nix werden.
Genau so wenn du über void* zurückcastest.
Oder sonst irgendwie Unsinn baust.

Unregistrierter

hustbaer schrieb:

Wenn du z.B. von "Context" zu "void*" castest, und dann von "void*" zu "OVERLAPPED*", dann wird das nix werden.
Genau so wenn du über void* zurückcastest.

Und wie sonst? Und warum geht das nicht?

hustbaer Mitglied 22:23:58 16.01.2011 Titel:

Du musst direkt von Context* zu OVERLAPPED* casten, damit der Zeiger entsprechend angepasst wird.

Wenn du von Context* zu void* castest, dann darfst du den void* den du bekommst nur wieder zurück zu Context* casten. Den so erhaltenen void* zu einer Basisklasse von Context* zu casten *kann* gehen, ist aber laut Standard undefiniert, und daher einfach falsch.
(Und es geht eben auch oft genug wirklich nicht.)

Alles C++ Grundlagen.

ps.:

BTW: der Fehler ist - wenn dein Beispielcode deinem Programm entspricht - eh ein anderer (sehr ähnlich, aber nix mit void*):

C/C++ Code:
Context* context GetQueuedCompletionStatus(..., (OVERLAPPED*)&context); // das ist Humbug*

C/C++ Code:
Context* context GetQueuedCompletionStatus(..., (OVERLAPPED*)&context); // das ist Humbug*

C/C++ Code:
Context* context GetQueuedCompletionStatus(..., (OVERLAPPED*)&context); // das ist Humbug*

Richtig geht das so:

C/C++ Code:
OVERLAPPED* overlapped; GetQueuedCompletionStatus(..., &overlapped); // Kein Cast nötig Context* context = static_cast<Context>(overlapped); // Jetzt casten wir den Zeiger (was OK ist), und nicht einen Zeiger auf einen Zeiger (was Humbug wäre)*

C/C++ Code:
OVERLAPPED* overlapped; GetQueuedCompletionStatus(..., &overlapped); // Kein Cast nötig Context* context = static_cast<Context>(overlapped); // Jetzt casten wir den Zeiger (was OK ist), und nicht einen Zeiger auf einen Zeiger (was Humbug wäre)*

C/C++ Code:
OVERLAPPED* overlapped; GetQueuedCompletionStatus(..., &overlapped); // Kein Cast nötig Context* context = static_cast<Context>(overlapped); // Jetzt casten wir den Zeiger (was OK ist), und nicht einen Zeiger auf einen Zeiger (was Humbug wäre)*

Der Grund warum es nicht funktioniert, ist dass "Zeiger auf Context" und "Zeiger auf OVERLAPPED" zwei unverwandte Typen sind. Anders gesagt: du kannst nicht T** zu U** casten, egal wie T und U verwandt sind, da T* und U* eben nicht verwandt sind.
Sorry, kann es grad auf die Schnelle nicht besser erklären, bzw. hab keine Zeit es besser/näher zu erklären.

zeusosc Mitglied 02:16:31 17.01.2011 Titel:

hustbaer schrieb:

Du musst direkt von Context* zu OVERLAPPED* casten, damit der Zeiger entsprechend angepasst wird.

Wenn du von Context* zu void* castest, dann darfst du den void* den du bekommst nur wieder zurück zu Context* casten. Den so erhaltenen void* zu einer Basisklasse von Context* zu casten *kann* gehen, ist aber laut Standard undefiniert, und daher einfach falsch.
(Und es geht eben auch oft genug wirklich nicht.)

Alles C++ Grundlagen.

Jo,
wenn man eine Inheritclass zu einer baseclass über einen void direkt
konvertiert, muss man darauf achten, dass es die erste Basisklasse ist.
Ansonsten muss der this ptr adjustiert werden,..

Mal grob pseudomäßig:

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	class Inherit: BaseA, BaseB {} //... LPVOID blub =(LPVOID) new Inerhit; BaseA* basA = (BaseA) blub; //geht, da nach msdn spec für MSVC BaseA erste addy ist BaseB* basB = (BaseB) (blub +sizeof(BaseA)); //Adjustiere zeiger // BaseB liegt hinter BaseA, sizeof(BaseA) sollte auch die die größe der vftbl beinhalten

C/C++ Code:
1 2 3 4 5 6 7 8	class Inherit: BaseA, BaseB {} //... LPVOID blub =(LPVOID) new Inerhit; BaseA* basA = (BaseA) blub; //geht, da nach msdn spec für MSVC BaseA erste addy ist BaseB* basB = (BaseB) (blub +sizeof(BaseA)); //Adjustiere zeiger // BaseB liegt hinter BaseA, sizeof(BaseA) sollte auch die die größe der vftbl beinhalten

C/C++ Code:
1 2 3 4 5 6 7 8	class Inherit: BaseA, BaseB {} //... LPVOID blub =(LPVOID) new Inerhit; BaseA* basA = (BaseA) blub; //geht, da nach msdn spec für MSVC BaseA erste addy ist BaseB* basB = (BaseB) (blub +sizeof(BaseA)); //Adjustiere zeiger // BaseB liegt hinter BaseA, sizeof(BaseA) sollte auch die die größe der vftbl beinhalten

Die adjustage sollte man aber compiler/architektur-spezifisch explecit nochmal prüfen, bevor man sich darauf verlässt das es "einfach" funktioniert,...

grüßli

hustbaer Mitglied 02:53:28 17.01.2011 Titel:

Zitat:

Jo,
wenn man eine Inheritclass zu einer baseclass über einen void direkt
konvertiert, muss man darauf achten, dass es die erste Basisklasse ist.

Bist du sicher dass das dann definiert ist (laut Standard)?
Ich müsste da erst nachsehen...

zeusosc Mitglied 00:58:26 20.01.2011 Titel:

Hi,.

100% sicher bin ich jetzt gerade net,..wo du fragst.
Aber ich schaue mal morgen nach.

gn8

Unregistrierter

Ouch, Grundlagenlücke!
Aber: Was, wenn man es statt mit Vererbung so macht:

C/C++ Code:
struct Context { OVERLAPPED overlapped; // ... };

C/C++ Code:
struct Context { OVERLAPPED overlapped; // ... };

C/C++ Code:
struct Context { OVERLAPPED overlapped; // ... };

Ist "GetQueuedCompletionStatus(..., (OVERLAPPED**)&context);" dann OK? Ich denke schon, denn so, ganz "roh", dürfte ja "Context" und "OVERLAPPED" bis hin zu sizeof(OVERLAPPED) Bytes "speichergleich" sein...

Martin Richter (MVP für C++) · Martin Richter Moderator 11:34:53 20.01.2011 Titel:

Hi schrieb:

Ouch, Grundlagenlücke!
Aber: Was, wenn man es statt mit Vererbung so macht:

C/C++ Code:
struct Context { OVERLAPPED overlapped; // ... };

C/C++ Code:
struct Context { OVERLAPPED overlapped; // ... };

C/C++ Code:
struct Context { OVERLAPPED overlapped; // ... };

Ist "GetQueuedCompletionStatus(..., (OVERLAPPED**)&context);" dann OK? Ich denke schon, denn so, ganz "roh", dürfte ja "Context" und "OVERLAPPED" bis hin zu sizeof(OVERLAPPED) Bytes "speichergleich" sein...

Nein!
Das hat doch nicht mit Vererbung zu tun.

Außerdem: Versuche casts zu Vermeiden. Gerade wen es hier in keiner Weise nötig ist.

1. Würde ich dennoch den Member in der Context Struktur direkt adressieren.
2. Würde ich nicht darauf bauen, dass overlapped der ertse Parameter der Strutktur bleibt.
3. Wenn überhaupt würde ich von OVERLAPPED ableiten:

Code:
struct Context : public OVERLAPPED { // ... };

Code:
struct Context : public OVERLAPPED { // ... };

Code:
struct Context : public OVERLAPPED { // ... };

Aber selbst das ist IMHO mieses Design.
4. Ein Zeiger auf einen Zeiger Overlapped Struktur ist das:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	struct Context { OVERLAPPED overlapped; // ... }; //... Context myContext; LPOVERLAPPED p = &myContext.overlapped; GetQueuedCompletionStatus(..., &p, ...);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	struct Context { OVERLAPPED overlapped; // ... }; //... Context myContext; LPOVERLAPPED p = &myContext.overlapped; GetQueuedCompletionStatus(..., &p, ...);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	struct Context { OVERLAPPED overlapped; // ... }; //... Context myContext; LPOVERLAPPED p = &myContext.overlapped; GetQueuedCompletionStatus(..., &p, ...);

Jodocus Mitglied 11:46:04 20.01.2011 Titel:

Geht auch ohne Vererbung mit dem Makro CONTAINING_RECORD()

Martin Richter (MVP für C++) · Martin Richter Moderator 13:05:29 20.01.2011 Titel:

Jodocus schrieb:

Geht auch ohne Vererbung mit dem Makro CONTAINING_RECORD()

Ich habe doch geschrieben, dass es ohne Vererbung geht und auch besser wäre...
Ich verstehe Deinen Einwurf nicht.
Zudem löst es nicht das Grundproblem, dass der OP nämlich einen Zeiger auf einen Zeiger benötigt!

Jodocus Mitglied 13:22:35 20.01.2011 Titel:

>> dass der OP nämlich einen Zeiger auf einen Zeiger benötigt!

Hä? Den braucht er doch überhaupt nicht.
Mein Post war kein Einwand, sondern eine gängige Möglichkeit, aus einem Member das Container-Objekt zu ermitteln (was auch funktioniert, wenn OVERLAPPED nicht der erste Member der Struktur ist). :confused:

Martin Richter (MVP für C++) · Martin Richter Moderator 15:09:56 20.01.2011 Titel:

Jodocus schrieb:

Hä? Den braucht er doch überhaupt nicht.

Nicht?

Dann schau Dir mal die Definition von GetQueuedCompletionStatus an.
http://msdn.microsoft.com/en-us/library/aa364986(VS.85).aspx

Nach meinem Dafürhalten ist "LPOVERLAPPED *lpOverlapped" ein Zeiger auf einen Zeiger, und damit hat der OP anscheinend Probleme...
Just my 2 cents!

Unregistrierter

Ich glaube, ich verwende lieber den completion key (unsigned int*)

Sollte eigentlich genau so klappen. Man hat dann halt keine verschiedenen Kontexte für zB. AcceptEx und WSARecv, aber dann packt man halt alles nötige in eine einzige ClientContext-Struktur.
Oder warum sollte man das nicht machen?

Jodocus Mitglied 17:30:54 20.01.2011 Titel:

Huch, da hab ich das LP überlesen, sorry Martin.

Anyway, das Problem ist ja nicht der Doppelzeiger, mit dem hat er ja eigentlich fast nichts zu tun, bisauf das Übergeben der Adresse.

@ TS: Das ist doch ganz einfach:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	enum operation_type { accept, send, recv, ... }; // POD struct container { operation_type type; WSAOVERLAPPED overlapped; }; container c = new container; std::memset(c, sizeof c, 0); c->type = accept; AcceptEx(..., c, ...); ... WSAOVERLAPPED ol_ptr = 0; GetQueuedCompletionStatus(..., &ol_ptr, ...); container* con_ptr = CONTAINING_RECORD(ol_ptr, container, overlapped); event_workers[con_ptr->type](..., con_ptr, ...);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	enum operation_type { accept, send, recv, ... }; // POD struct container { operation_type type; WSAOVERLAPPED overlapped; }; container c = new container; std::memset(c, sizeof c, 0); c->type = accept; AcceptEx(..., c, ...); ... WSAOVERLAPPED ol_ptr = 0; GetQueuedCompletionStatus(..., &ol_ptr, ...); container* con_ptr = CONTAINING_RECORD(ol_ptr, container, overlapped); event_workers[con_ptr->type](..., con_ptr, ...);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	enum operation_type { accept, send, recv, ... }; // POD struct container { operation_type type; WSAOVERLAPPED overlapped; }; container c = new container; std::memset(c, sizeof c, 0); c->type = accept; AcceptEx(..., c, ...); ... WSAOVERLAPPED ol_ptr = 0; GetQueuedCompletionStatus(..., &ol_ptr, ...); container* con_ptr = CONTAINING_RECORD(ol_ptr, container, overlapped); event_workers[con_ptr->type](..., con_ptr, ...);

Mit dem CONTAINING_RECORD-Makro erhälst du den Container, der das OVERLAPPED-Objekt enthält (intern natürlich per Casts). In einem Array von Funktoren kannst du dann entsprechende Funktionen sammeln, die über eine Operation-ID dispatcht werden.

>> Ich glaube, ich verwende lieber den completion key (unsigned int*)

Den solltest du benutzen, aber nicht für Per-I/O-Daten. Der Completion-Key ist für gewöhnlich der Socket-Deskriptor, auf dem die Operation stattgefunden hat.

Edit: Hoffentlich bist du auch über den korrekten Umgang mit AcceptEx() aufgeklärt.

Unregistrierter

WSAOVERLAPPED overlapped; <- müsste dann aber die erste Membervariable sein, damit es funktioniert

Jodocus Mitglied 18:18:53 20.01.2011 Titel:

Nö, der Offset wird intern abgezogen.

Wird bei mir jedenfalls so definiert:

C/C++ Code:
#define CONTAINING_RECORD(address,type,field) ((type* )( (PCHAR)(address) - (ULONG_PTR)(&((type )0)->field)))

C/C++ Code:
#define CONTAINING_RECORD(address,type,field) ((type* )( (PCHAR)(address) - (ULONG_PTR)(&((type )0)->field)))

C/C++ Code:
#define CONTAINING_RECORD(address,type,field) ((type* )( (PCHAR)(address) - (ULONG_PTR)(&((type )0)->field)))

Unregistrierter

Dann darfst du aber bei AcceptEx nicht direkt c übergeben sondern &c.overlapped

Unregistrierter

Hmm, guck ich mir mal an.

Jodocus schrieb:

Den solltest du benutzen, aber nicht für Per-I/O-Daten.

Warum nicht? Kann auch gleich eine ganze Struktur übergeben.
Und ich brauche ja pro Client nicht mehr als einen Kontext und einen WSARecv-Aufruf.
Dann bei GetQueuedCompletionStatus() habe ich den Clientkontext verfügbar. Ist doch genau so wie mit dem OVERLAPPED *.

Jodocus schrieb:

Edit: Hoffentlich bist du auch über den korrekten Umgang mit AcceptEx() aufgeklärt.

Vielleicht kannst du dazu noch kurz was erwähnen?

(Außer natürlich, dass man sich unbedingt den Funktionszeiger holen sollte. Und vllt. noch setsockopt mit SO_UPDATE_ACCEPT_CONTEXT. Und natürlich immer schön null-initialisierte OVERLAPPED-Strukturen zu verwenden :rolleyes:

).

Jodocus Mitglied 18:43:01 20.01.2011 Titel:

>> Dann darfst du aber bei AcceptEx nicht direkt c übergeben sondern &c.overlapped

Logo.

>> Warum nicht? Kann auch gleich eine ganze Struktur übergeben.

Weil eine Verbindung nicht viel mit einer Operation zu tun hat. Per-Handle-Data und Per-I/O-Data sind doch in diesem Kontext verschieden.
Für Per-Handle-Data speichert man so Sachen wie Socket-Deskriptor, gesendete/empfangene Bytes, Adresse etc., hingegen benutzt die Per-I/O-Data für Sachen wie Fehlercode, Puffer, Operationstyp etc. Wenn du das alles in eine einzige monolithische Struktur presst, hast du oft Informationen an manchen Stellen, die du gar nicht brauchst.
Du kannst es natürlich machen, technisch spricht auch nichts dagegen. Es ist eben üblich, I/O-Completionports auf diese Weise zu handhaben. (jaja, ich weiß, Dogmatismus

)

>> Vielleicht kannst du dazu noch kurz was erwähnen?

Benutzt du den übergebenen Puffer, um gleich auch Daten vom Client zu empfangen?

Unregistrierter

Alles klar, werd ich bedenken. Danke!

Jodocus schrieb:

Benutzt du den übergebenen Puffer, um gleich auch Daten vom Client zu empfangen?

Nope. Hab ich lieber gelassen, wegen stale clients.
Macht für mich auch irgendwie überhaupt keinen Sinn, bei AcceptEx schon was zu empfangen. Wobei... soll das etwa für "Autorisierungen" sein?

Jodocus Mitglied 20:29:19 20.01.2011 Titel:

>> Wobei... soll das etwa für "Autorisierungen" sein?

Nö, für Performance. Du kannst im Kernelmode gleich 2 Operationen ausführen, anstatt explicit WSARecv() zu benutzten (du sparst dir einen switch in den Usermode). Aber schon AcceptEx() brauchst du nur bei äußerster Performance. Was programmierst du überhaupt?

>> Nope. Hab ich lieber gelassen, wegen stale clients.

Dafür gibt es ja Lösungsmöglichkeiten.

Unregistrierter

Jo, aber wenn's nicht sein muss...

Eigentlich nur nen kleinen Server/Client Core für ein, zwei kleinere zukünftige Projekte.
Aber das Prinzip completion ports gefällt mir am besten. Deshalb möchte ich es verwenden und mich nicht mit select-Gefrickel o.Ä. herumschlagen und auch gleich was lernen.

Jodocus Mitglied 21:51:04 20.01.2011 Titel:

Naja, nachdem du dir das angeguckt hast, kannst du auch gleich zu boost::asio greifen.