Różnica między IntPtr i UIntPtr

Question

Szukałem na P/Invoke deklarację RegOpenKeyEx gdy zauważyłem ten komentarz na stronie:

Zmieniono IntPtr do UIntPtr: podczas wywoływania z IntPtr dla uchwytów, można uruchomić w Overflow. UIntPtr to właściwy wybór, jeśli chcesz, aby działał poprawnie na platformach 32- i 64-bitowych.

To nie ma sensu do mnie: zarówno IntPtr i UIntPtr mają reprezentować wskazówek więc ich wielkość powinna odpowiadać bitness systemu operacyjnego - albo 32 bity lub 64 bity. Ponieważ nie są to liczby, ale wskaźniki, ich podpisane wartości liczbowe nie powinny mieć znaczenia, tylko bity, które reprezentują adres, na który wskazują. Nie mogę wymyślić żadnego powodu, dla którego byłoby różnica między tymi dwoma, ale ten komentarz sprawił, że jestem niepewny.

Czy istnieje konkretny powód używania UIntPtr zamiast IntPtr? Według documentation:

typu IntPtr CLS jest zgodny, a typ UIntPtr nie. W środowisku wykonawczym wspólnego języka używany jest tylko typ IntPtr. Typ UIntPtr jest dostarczany głównie w celu zachowania symetrii architektury z typem IntPtr.

To oczywiście oznacza, że ​​nie ma różnicy (o ile ktoś nie próbuje przekonwertować wartości na liczby całkowite). Czy powyższy komentarz z serwisu pinvoke.net jest nieprawidłowy?

Edit:

Po przeczytaniu MarkH's answer, zrobiłem trochę sprawdzenia i okazało się, że aplikacje .NET nie są duże adres świadomy i może obsługiwać tylko 2 GB wirtualnej przestrzeni adresowej, gdy skompilowany w wersji 32-bitowej tryb. (Można użyć flagi hack, aby włączyć flagę dużego adresu, ale odpowiedź MarkH pokazuje, że kontrole w .NET Framework będą powodować błędy, ponieważ zakłada się, że przestrzeń adresowa ma tylko 2 GB, a nie 3 GB.)

Oznacza to, że wszystkie poprawne adresy pamięci wirtualnej, które może posiadać wskaźnik (w odniesieniu do .NET Framework) będą między 0x00000000 i 0x7FFFFFFF. Gdy ten zakres zostanie przetłumaczony na podpisany int, żadne wartości nie będą ujemne, ponieważ najwyższy bit nie jest ustawiony. To wzmacnia moje przekonanie, że nie ma żadnej różnicy w używaniu IntPtr vs UIntPtr. Czy moje rozumowanie jest poprawne?

Fermat2357 zaznaczył, że powyższa edycja jest nieprawidłowa.

Answer 1

UIntPtr i IntPtr wewnętrzne są realizowane jako

private unsafe void* m_value; 

Masz rację zarówno po prostu tylko zarządzający bity, które reprezentują adres.

Jedyne, co mogę myśleć o problemie z przepełnieniem, to próba wykonania arytmetyki wskaźnikowej. Obie klasy obsługują dodawanie i odejmowanie przesunięć. Ale także w tym przypadku binarna reprezentacja powinna być w porządku po takiej operacji.

Z mojego doświadczenia chciałbym również wybrać UIntPtr, ponieważ myślę, że na wskaźnik jako obiekt unsigned. Ale to nie jest istotne i tylko moja opinia.

Wygląda na to, że nie ma to znaczenia, jeśli używasz w swojej sprawie IntPtr lub UIntPtr.

EDIT:

IntPtr jest zgodny z CLS, ponieważ istnieją języki na górze CLR, który nie obsługuje niepodpisany.

Answer 2

To oczywiście oznacza, że ​​nie ma różnicy (o ile ktoś nie próbuje przekonwertować wartości na liczby całkowite).

Niestety, framework próbuje to zrobić (gdy jest skompilowany specjalnie dla x86). Zarówno konstruktor IntPtr(long), jak i metody ToInt32() próbują odrzucić wartość do int w wyrażeniu checked. Oto implementacja widziana przy użyciu symboli debugowania szkieletu.

public unsafe IntPtr(long value) 
    { 
     #if WIN32 
      m_value = (void *)checked((int)value); 
     #else 
      m_value = (void *)value; 
     #endif 
    } 

Oczywiście sprawdzane wyrażenie wyrzuci wyjątek, jeśli wartość jest poza zakresem. Numer UIntPtr nie przepełnia się dla tej samej wartości, ponieważ próbuje on zamiast tego obsłużyć do uint.

Answer 3

Różnica między IntPtr \ UIntPtr jest taka sama jak różnic występujących pomiędzy: Int32 \ UInt32 (tzn., To wszystko o tym, jak numery się interpretować)

Zwykle, to nie ma znaczenia, który wybierzesz, ale, jak wspomniano, w niektórych przypadkach może wrócić, by cię ugryźć.

(nie jestem pewien, dlaczego MS wybrał IntPtr zacząć (CLS zgodności, etc ,.), pamięć jest traktowane jako DWORD (U32), co oznacza, że ​​jest bez znaku, a więc preferowana metoda powinna być UIntPtr, nie ? IntPtr, prawy)

Nawet: UIntPtr.Add()

Wydaje mi źle, to zajmuje UIntPtr jako wskaźnik, oraz 'int' dla offsetu. (Kiedy dla mnie "uint" miałoby więcej sensu, dlaczego karmić podpisaną wartość niepodpisaną metodą, kiedy, bardziej niż prawdopodobne, że kod wyrzucił ją do "uint" pod maską/facepalm)

I osobiście wolałbym UIntPtr od IntPtr tylko dlatego, że niepodpisane wartości pasują do wartości pamięci bazowej, z którą pracuję. :)

---

Btw, ja prawdopodobnie skończyć tworząc własny typ wskaźnika (używając UInt32), zbudowany specjalnie dla pracujących bezpośrednio z pamięci. (Zgaduję, że UIntPtr nie złapie wszystkich możliwych złych problemów z pamięcią, tj. 0xBADF00D, itd., Itd. Który jest CTD czekający na zdarzenie ... Będę musiał zobaczyć, jak wbudowany typ najpierw zajmuje się rzeczami, miejmy nadzieję, że kontrola zerowa \ zero poprawnie odfiltrowuje takie rzeczy.)