Почему у Win32-API есть столько пользовательских типов?
Я плохо знаком с API Win32, и много новых типов начинают смущать меня.
Некоторые функции берут 1-2 ints и 3 UINTS как аргументы.
- Почему они не могут просто использовать ints? Что такое UINTS?
Затем существуют те другие типы:
DWORD LPCWSTR LPBOOL
- Снова, я думаю, что "примитивные" типы C были бы достаточно - почему представляют 100 новых типов?
Этот был болью: WCHAR*
Я должен был выполнить итерации через него и push_back каждого символа к станд.:: представьте в виде строки, поскольку не было другого способа преобразовать его в один. Ужасный.
- Почему
WCHAR? Почему изобретают велосипед? Они, возможно, просто использовалиchar*вместо этого, или?
4 ответа
Windows API был впервые создан еще в 1980-х годах, и на протяжении многих лет ему приходилось поддерживать несколько различных архитектур ЦП и компиляторов. Они перешли от однопользовательских однопроцессных автономных систем к многопользовательским многоядерным сетевым системам, ориентированным на безопасность. Им приходилось решать проблемы с 16-битными против 32-битных процессоров, а теперь и с 64-битными. Им приходилось обходить проблемы с компиляторами до ANSI C. В ранние нестандартные времена им приходилось поддерживать компиляторы C ++. Им пришлось иметь дело с сегментированной памятью. Они должны были поддерживать интернационализацию до того, как появился Unicode. Они должны были поддерживать некоторую совместимость на уровне исходного кода с MS-DOS, с OS / 2 и Mac OS. Им приходилось работать на нескольких поколениях чипов Intel, PowerPC, MIPS, Alpha и ARM. Один и тот же базовый API используется для настольных, серверных, мобильных и встроенных систем.
Еще в 1980-х годах C считался языком высокого уровня (да, действительно!), И многие люди считали хорошим тоном использовать абстрактные типы, а не просто указывать все как примитив int , char или void * . Когда у нас не было IntelliSense, информационных подсказок, браузеров кода, онлайн-документации и тому подобного, такие подсказки по использованию были полезны и упрощали перенос кода между разными компиляторами и разными языками программирования.
Да, это ужасный беспорядок, но это не значит, что они сделали что-то не так.
UINT - это целое число без знака. Если значение параметра не может быть отрицательным, имеет смысл указать unsigned. LPCWSTR - это указатель на массив константных широких символов, а WCHAR * не является константой.
Вам, вероятно, следует скомпилировать свое приложение для UNICODE при работе с широкими символами или использовать процедуру преобразования для преобразования из узкого в широкий.
http://msdn.microsoft.com/en- us / library / dd319072% 28VS.85% 29.aspx
http://msdn.microsoft.com/en-us/library/dd374083%28v=VS.85%29.aspx
Мой коллега сказал бы: «Нет проблемы, которую нельзя было бы решить (запутать?) с помощью косвенного обращения.«В WIN32 вы будете иметь дело с WCHAR, UINT и т. Д., И вы к этому привыкнете. Вам не придется беспокоиться, когда вы развертываете ту DLL, базовый тип которой компилируется WCHAR или UNIT - она будет« просто работать » .
Лучше прочитать некоторую документацию, чтобы привыкнуть к ней. Особенно о поддержке широких символов (WCHAR и т. Д.). В MSDN есть хорошее определение для WCHAR .
{ {1}}Win32 на самом деле имеет очень мало примитивных типов. То, что вы видите, - это десятилетия создания #defines, typedef и венгерской нотации. Потому что было так мало типов, и разработчики intellisense не давали себе «подсказок» относительно того, что на самом деле должен делать конкретный тип.
Например, нет логического типа, но есть представление целого числа с «псевдонимом», которое сообщает вам, что определенная переменная должна рассматриваться как логическая. Взгляните на содержимое WinDef.h, чтобы понять, что я имею в виду.
Вы можете посмотреть здесь: http://msdn.microsoft.com/en-us/library/aa383751 (VS.85) .aspx , чтобы увидеть настоящая верхушка айсберга. Например, обратите внимание на то, что HANDLE является базовым определением типа для любого другого объекта, который является «дескриптором» объекта Windows. Конечно, HANDLE определен где-то еще как примитивный тип.