Welche Größe hat ein Zeiger auf eine Klasse?

in deinem fall ist das nur ne falschmeldung. du benutzt ja schon die funktion die auf 64-bit vorbereitet ist.

FireFlow

CodeFinder schrieb:

Ein Zeiger ist IMMER (auf einem 32Bit-Rechner) 4 Bytes groß.

Nicht alle...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/getting_ready_for_64_bit_windows.asp
http://cache-www.intel.com/cd/00/00/01/79/17969_codeclean_r02.pdf

In C++ gibts auch Zeiger die größer sind als 4Byte, nen tollter Artikel dazu: http://www.codeproject.com/cpp/FastDelegate.asp

groovemaster

Dein Problem liegt vermutlich an deinem Platform SDK, denn GetWindowLongPtr gibt nicht LONG, sondern LONG_PTR zurück. Dann gibt's auch keine Warnungen. Habe hier selbst ein Platform SDK von 2005, und da wird LONG_PTR nur bei _WIN64 zurückgegeben. Was aber eigentlich immer so sein sollte, egal ob _WIN32 oder _WIN64. Ich würde die 64 Bit Kompatibilitätsüberwachung auf jeden Fall eingeschaltet lassen und den Rückgabewert erst nach LONG_PTR casten.

pThis = (myClass*) (LONG_PTR) GetWindowLongPtr( hWnd, GWLP_USERDATA );

Sieht zwar etwas seltsam aus, sollte aber problemlos laufen. Wobei ich als C++ Programmierer natürlich andere Casts verwenden würde.

CodeFinder

Dann hab ich nochmal ne Frage:
Aber Zeiger sind doch auf 64Bit Systemen größer (bzog. auf den Speicherverbrauch) als
auf 32Bit Systemen, oder ?

...Wieviel ?

CodeFinder schrieb:

Dann hab ich nochmal ne Frage:
Aber Zeiger sind doch auf 64Bit Systemen größer (bzog. auf den Speicherverbrauch) als
auf 32Bit Systemen, oder ?

...Wieviel ?

LONG_PTR ist ja auch nicht immer gleich groß, sondern groß genug den Zeiger zu speichern.

HumeSikkins

CodeFinder schrieb:

Dann hab ich nochmal ne Frage:
Aber Zeiger sind doch auf 64Bit Systemen größer (bzog. auf den Speicherverbrauch) als
auf 32Bit Systemen, oder ?

...Wieviel ?

Datenzeiger sind auf gängigen 64-bit Systemen doppelt so groß wie auf gängigen 32-bit Systemen, nämlich 8-Byte.

CodeFinder

Hm ok danke erstmal...

HumeSikkins schrieb:

CodeFinder schrieb:

Dann hab ich nochmal ne Frage:
Aber Zeiger sind doch auf 64Bit Systemen größer (bzog. auf den Speicherverbrauch) als
auf 32Bit Systemen, oder ?

...Wieviel ?

Datenzeiger sind auf gängigen 64-bit Systemen doppelt so groß wie auf gängigen 32-bit Systemen, nämlich 8-Byte.

Hm...daraus kann man doch dann schließen , das auf einem 32bit System, Zeiger 4 Byte verbrauchen...
Warum stimmt das:

CodeFinder schrieb:

Ein Zeiger ist IMMER (auf einem 32Bit-Rechner) 4 Bytes groß.

dann nicht ?

Danke schon mal für die Aufklärung

@groovemaster:
Der Code lässt sich in der Tat problemlos ohne Warnungen kompilieren. Und hierbei sehe ich auch keinerlei Probleme beim Umstieg auf 64 Bit. Was mich eher zum grübeln bringt ist:

SetWindowLongPtr(hWnd,GWLP_USERDATA,(LONG)pThis);

Caste ich hier impliziet

(LONG)(LONG_PTR)pThis

würde ich hier bei der 64Bit Version Probleme bekommen. da ich den LONG_PTR in einen LONG kovertiert habe, was auch nach der neuen SDK immer noch 32Bit sein müssten. Bei

(LONG_PTR)pThis

wäre das Statement zwar korrekt, allerdings kann ich es nicht ohne Warunungen mit meinem 32Bit Compiler ausführen.

Sven

HumeSikkins

CodeFinder schrieb:

Hm ok danke erstmal...

HumeSikkins schrieb:

CodeFinder schrieb:

Dann hab ich nochmal ne Frage:
Aber Zeiger sind doch auf 64Bit Systemen größer (bzog. auf den Speicherverbrauch) als
auf 32Bit Systemen, oder ?

...Wieviel ?

Datenzeiger sind auf gängigen 64-bit Systemen doppelt so groß wie auf gängigen 32-bit Systemen, nämlich 8-Byte.

Hm...daraus kann man doch dann schließen , das auf einem 32bit System, Zeiger 4 Byte verbrauchen...
Warum stimmt das:

CodeFinder schrieb:

Ein Zeiger ist IMMER (auf einem 32Bit-Rechner) 4 Bytes groß.

dann nicht ?

Es gibt einen Unterschied zwischen Datenzeigern und Funktionszeigern. Datenzeiger (Zeiger auf einen Typen wie int, char, FooBar) sind auf gängigen 32-bit Systemen *immer* 4-Byte groß und Konvertierungen zwischen dem Standard-Integer (int bzw. long) und einem solchen Zeiger sind hier gefahrlos möglich.

Für Funktionszeiger (dazu gehören insbesondere auch Memberfunktionszeiger) hingegen muss das nicht gelten. Normale Funktionszeiger sind in der Regel zwar auch nur Adressen (und damit äquivalent zu Datenzeigern), der Standard schreibt dies aber nicht vor. Spätestens bei Memberfunktionszeigern wird es allerdings komplizierter, da hier zusätzliche Informationen gespeichert werden müssen (z.B. wenn virtuelle Funktionen ins Spiel kommen).

Btw: Die Grütze die der VC 6.0 bei Memberfunktionszeigern macht (siehe dazu den von Dr. Prof verlinkten Artikel) ist allerdings nicht Standard-Konform.

CodeFinder

LOL, ok dann danke ich dir mal für deine Ausführungen

groovemaster

sgergen schrieb:

Was mich eher zum grübeln bringt ist:
SetWindowLongPtr(hWnd,GWLP_USERDATA,(LONG)pThis);
Caste ich hier impliziet
(LONG)(LONG_PTR)pThis
würde ich hier bei der 64Bit Version Probleme bekommen. da ich den LONG_PTR in einen LONG kovertiert habe, was auch nach der neuen SDK immer noch 32Bit sein müssten.

Hmmm...habe jetzt noch mal in meinem 2005er SDK nachgeschaut, und da ist GetWindowLongPtr/SetWindowLongPtr tatsächlich nur ein define auf GetWindowLong/SetWindowLong. Das ist meiner Meinung nach ein Bug, da dadurch die Signatur verfälscht wird. Mich würde mal interessieren, was Jochen dazu meint. Wie auch immer, erstmal könntest du versuchen, ein aktuelles Platform SDK zu installieren. Evtl. ist das dort behoben. Sollte das nicht helfen, hätte ich als zweite Möglichkeit noch Folgendes anzubieten:

#ifdef GetWindowLongPtr
    #undef GetWindowLongPtr
    LONG_PTR GetWindowLongPtr(HWND hWnd, int nIndex);
#endif

#ifdef SetWindowLongPtr
    #undef SetWindowLongPtr
    LONG_PTR SetWindowLongPtr(HWND hWnd, int nIndex, LONG_PTR dwNewLong);
#endif

Das schreibst du dann _nachdem_ <windows.h> eingebunden wurde, und _bevor_ du die Funktionen aufrufst.
Bin zwar kein Freund von solchen Hacks, momentan würden mir aber nur Lösungen einfallen, die mir noch unsympathischer wären.