Windows API - typové aliasy

[fortran1986]

Ahojte pozerám dokumentáciu k windows API a všade sa používajú makrá a typové aliasy napr:

Kód: [Vybrat]

BOOL RegisterHotKey(
  HWND hWnd,
  int  id,
  UINT fsModifiers,
  UINT vk
);
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerhotkey

UINT = unsigned int - je to dlhší názov ale aspoň hneď na prvý pohľad viem o čo ide.
BOOL = int - nové C++ už má aj natívny bool takže ten budem preferovať
HWND = pointer asi na int? - handle window - ID okna keďže je to konzolová appka tak sem dám NULL alebo v modernom c++ nullptr - ktoré je bezpečnejšie

Otázka je mám používať natívne typy C++ alebo tieto neštastné aliasy od MS? Viem že to malo zmysel keď boli 16 a 32 bit windows tak jedným aliasom sa dalo stanoviť aký typ bude ten alias zastupovať ale dnes neviem či to ešte má zmysel? Ak áno tak aký?

[Reklama]

[oss]

WinApi je C-eckove api, v nom boll narozdiel od C++ nieje.

Tie "nestandardne aliasy" su v skutocnosti stanard pre cele Win API, kovli konzistencii na roznych systemoch.
To ze ma nejake API vlastne typy nie je v C/C++ nic nezvycajne (robi sa to kovli prenositelnosti a kvoli tomu, ze niektore veci niesu definovane napriklad ci je typ char signed alebo unsigned).

Ja by som pouzival WinApi typy, ak ti velmi vadia kludne si nad nimi napis wrapper. WinApi typy davaju logiku a su samopospisne, ked clovek pochopi princip ich konvencie.

[Jiří Havel]

Kolem winapi doporučuju používat ty jejich typy. Ono je celé winapi používá konzistentně.

Třeba to HWND nebo HANDLE je pointer na "něco". Není důležité na co, ale že to je rukojeť k nějakému objektu.

Celé použití winapi ale doporučuju nepropustně zabalit do jednoho modulu za nějaké vlastní rozhraní. Pokud se vám #include <windows.h> rozuteče po větším projektu, tak vaše zadek pozná středověk.
Windows.h definuje mračno nenápadných a maximálně destruktivních maker, které můžou dělat neskutečný binec při překladu a linkování.

[mhi]

Pokud se vám #include <windows.h> rozuteče po větším projektu, tak vaše zadek pozná středověk.
Windows.h definuje mračno nenápadných a maximálně destruktivních maker, které můžou dělat neskutečný binec při překladu a linkování.

To mne pobavilo :-). Muzete nejaka makra zminit ?  Ono tam toho je dost co muze byt potenc. nebezpecne, ale pri trose opatrnosti v tom nevidim takovy problem, API jako takove mi prijde celkem rozumne navrzene, doprasili to IMHO az zmenami, kdy uz v MS nejspis puvodni architekti z VMS nebyli...

[Ivan Brezina]

Napr se to bije s stl.(popr. s math)  definuje si to makra min a max.
Proto vsude zaryte pouzivam:

(std::max)(sizes[column], v.length())

Aby mi to windows.h nerozbil.

[Reklama]

[Jiří Havel]

To mne pobavilo :-). Muzete nejaka makra zminit ?  Ono tam toho je dost co muze byt potenc. nebezpecne, ale pri trose opatrnosti v tom nevidim takovy problem, API jako takove mi prijde celkem rozumne navrzene, doprasili to IMHO az zmenami, kdy uz v MS nejspis puvodni architekti z VMS nebyli...

Min a max jsou provalené. Ale z fleku mě napadají další dva ukázkové příklady:

1) Každá winapi funkce co bere jako parametr string je ve skutečnosti makro. Můžete třeba strávit spoustu času hledáním důvodu proč linker odmítá vaši třídu s metodou CreateFile. Makra nerozlišují třídy a metody a pak stačí aby do jednoho cpp to windows.h probublalo a do druhého ne. A CreateFile je jen jeden příklad z mnoha.

2) Strávil jsem hromadu času zjišťováním, proč mi funkce SetRange( float near, float far ) při kompilaci generuje úplně nesmyslné hlášky. Ještě, že jsem starý a pamatuju DOS. Nic z té chybové hlášky mi nenaznačilo, že se jméno far odmakrovalo do zapomnění.

C preprocesor a makra jsou past vedle pasti. Makra totálně ignorují jmenné prostory a pak záleží na pořadí includů. A ten strom includů je i pro relativně malé projekty něco, co lidský mozek nemá šanci rozumně pobrat. Proto se taky v novém kódu makra definují stylem FIRMA_PROJEKT_VLASTNI_JMENO aby to nemělo šanci vykonfliktit s nějakým příšetným jménem.

Winapi omlouvá jen to, že jeho návrháři ještě netušili, jakou prasárnu právě páchají.

[mhi]

Ted' jsem si uvedomil jak pri programovani dbam na to, abych nepouzival 'nebezpecna' jmena typu to minmax a jmena API funkci, i kdyz tam beru jen ty co znam a ten zbytek mi nedelal problemy, mozna kvuli tomu ze makra maji parametry a zatim jsem se netrefil.

Popravde receno nechapu, proc dualitu xxxW/xxxA nevyresili nejak jinak.

[fortran1986]

Win API metódy som obalil do tried a poriadne odtestoval a windows.h som presunul z hlavičkového súboru do implementačnej časti (*.cpp súbor).

Ďakujem za rady.

[Martin Dráb]

1) Každá winapi funkce co bere jako parametr string je ve skutečnosti makro. Můžete třeba strávit spoustu času hledáním důvodu proč linker odmítá vaši třídu s metodou CreateFile. Makra nerozlišují třídy a metody a pak stačí aby do jednoho cpp to windows.h probublalo a do druhého ne. A CreateFile je jen jeden příklad z mnoha.

Já jsem si zvykl přímo uvádět, jakou verzi takové API funkce budu volat (obvykle W). Nepředpokládám, že bych někdy potkal systém, který by unicode verze nepodporoval.

Popravde receno nechapu, proc dualitu xxxW/xxxA nevyresili nejak jinak.

Myslím si (ale nehledal jsem), že možná původně ani neexistovaly A a W varianty. Ty se objevily později, když bylo třeba řešit nový problém ANSI vs. Unicode. Ale rozhodně šel řešit jiným způsobem.

Problémy s C++ bych Windows API nevyčítal vzhledem k době vzniku.