c:\foo\foo.cpp(xx) : warning C4312: 'Typumwandlung': Konvertierung von 'LONG' in größeren Typ 'myClass *'

als Ergbenis z.B. von folgendem Aufruf:

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

GetWindowLongPtr gibt als Rückgabetyp LONG zurück. Ich verstehe dass mich der Compiler warnen möchte, dass pThis größer ist als LONG, was unter Window 32 bit int unsigned ist. Allerdings verstehe ich nicht, warum die Referenz auf die Klasse größer sein soll als 32Bit. Ich habe einen waschechten 32-Bit Prozessor, mit einem 32-Bit Compiler, warum sollten hier Adressen größer als 32 Bit aufgelöst werden, wenn es theoretisch maximal 4GB RAM geben kann (ich weiss. Sind in wirklichkeit weniger).
Irgendjemand der mit weiterhelfen kann?

mfg Sven

P.S. Alter C Programmierer der seine ersten Erfahrungen in C++ sammelt

Hm und warum warnt mich dann VC++ 2003 vor dem Datenverlust bei der Konvertierung?

Hmm, gute Frage...hast du mal probiert den (long)Return-Wert in void* zu casten...was sagt er dann (oder in*)

PS: nur dann NICHT verwenden...geht nur um die Warnung!

Sven

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

Nicht alle...

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.

...Wieviel ?

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.

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.

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

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

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.

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.