У меня были смешанные результаты в использовании.NET SgmlReader, который был первоначально запущен Chris Lovett и, кажется, был обновлен MindTouch.
Типы * _ PTR
были добавлены в Windows API для поддержки 64-битной адресации Win64.
Поскольку 32-битные API-интерфейсы обычно передавали указатели с использованием таких типов данных, как DWORD
, это было необходимо для создания новых типов для 64-битной совместимости, которые могли бы заменить DWORD
в 32-битных приложениях, но были расширены до 64-битных при использовании в 64-битных приложениях.
Так, например, разработчики приложений, которые хотят писать код, который работает как 32-битный ИЛИ 64-битный 32-битный API Windows SetWindowLong (HWND, int, LONG)
был изменен на SetWindowLongPtr (HWND, int, LONG_PTR)
В 32-битной сборке, SetWindowLongPtr
- это просто макрос, который разрешается в SetWindowLong
, и LONG_PTR
аналогично макрос, который разрешается в LONG
.
С другой стороны, в 64-битной сборке SetWindowLongPtr
- это API, который принимает 64-битную длину в качестве третьего параметра, а ULONG_PTR
- typedef для unsigned __int64
. . 123] Используя эти типы _PTR
, одна кодовая база может компилироваться как для целей Win32, так и для Win64.
При выполнении арифметических операций с указателями эти типы также следует использовать в 32-битном коде, который должен быть совместим с 64-битным.
поэтому, если вам нужно получить доступ к массиву с более чем 4 миллиардами элементов, вам нужно будет использовать INT_PTR, а не INT
CHAR* pHuge = new CHAR[0x200000000]; // allocate 8 billion bytes
INT idx;
INT_PTR idx2;
pHuge[idx]; // can only access the 1st 4 billion elements.
pHuge[idx2]; // can access all 64bits of potential array space.
Крис Бек в значительной степени прав. Стоит просто отметить, что эти типы _PTR - это просто типы, которые имеют ширину 32 бита в 32-битном приложении и 64 бита в 64-битном приложении. Это так просто.
Вы можете легко использовать, например, __int3264 вместо INT_PTR.