Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: fortran1986 02. 04. 2020, 19:20:57
-
Prosím Vás viete mi vysvetliť aký dôvod má používanie Maďarskej notácie? (Pred názvom identifikátoru skrátený názov typu)
A prečo si Microsoft robí z C++ ...Pascal?
Pri Windows API a MFC všetko čo sa dá premenuje nejakým nezmyselným aliasom, ktorý vyzerá ako z čias MS-DOSu a Turbo Pascalu.
Napr. "unsigned long" premenuje na pascalovský DWORD (double word), wchar_t* na PCWSTR a const wchar_t* na LPCWSTR a podobne. Neviem či sa mám z toho smiať či plakať. Má to nejaký hlbší význam (ak áno tak aký?) alebo to robí len tak samoúčelne aby nasral vývojárov?
A prečo názvy typov používa všetko veľkým písmenom? potom si myslím že ide o konštanty, chce tým nebodaj MS pritiahnuť vývojárov COBOLU?
-
Ja myslim, ze madarska notace pochazi z dob Win32 API a jedine tam to jeste preziva.
Ze v novejsich systemech (MFC, C#) uz se to nepouziva.
je to hnus a taky se mi to nelibi, ale uz je to historie.
-
Pri Windows API a MFC všetko čo sa dá premenuje nejakým nezmyselným aliasom, ktorý vyzerá ako z čias MS-DOSu a Turbo Pascalu.
Však Windows API je tak staré, že "z čias MS-DOSu" v zásadě pochází. Všimněte si třeba oblíbeného prefixu LP u typů ukazatelů, tzn. long pointerů (či far pointerů). V době chráněného režimu to nic neznamená, ale v době Win 3.x existovaly ukazatele "krátké" (v rámci segmentu) či "dlouhé/daleké" (segment i offset).
Osobně mám MS pojetí maďarské notace u názvů funkcí raději než jiné (pomlčky či žádné oddělovače). Lépe se to čte, protože člověk jasně vidí rozhranní slov (existují samozřejmě výjimky).
Prefixy u názvů parametrů mi přijdou zbytečné. Možná to mělo nějaký význam v minulosti (pokud takto měla pojmenované parametry každá funkce, nebylo nutné parsovat často jejich typ). A třeba v kernelovém API (jakože v jádře) se myslím vůbec nevyskytují (doba Windows 2000+).
Také bych spíše mluvil o C, ne o C++.
-
Cílem bylo snížit chybovost programátorů, přinést větší srozumitelnost api a zdrojových kódů skrze jednotný standard.
-
typedef int INT;
typedef LONG HRESULT;
Jestli tohle někomu přináší větší srozumitelnost tak asi bere nějaké drogy. Já bych tohle nevymyslel ani se 4 pivama.
-
Ja myslim, ze madarska notace pochazi z dob Win32 API a jedine tam to jeste preziva.
Ze v novejsich systemech (MFC, C#) uz se to nepouziva.
je to hnus a taky se mi to nelibi, ale uz je to historie.
Je to historie. MS se snaží to trochu krotit, ale těžko přepsat veškerou codebase, a že ji má fakt velkou.
typedef int INT;
typedef LONG HRESULT;
Jestli tohle někomu přináší větší srozumitelnost tak asi bere nějaké drogy. Já bych tohle nevymyslel ani se 4 pivama.
Svého času s v C typy psaly kapitálkama. Až časem se tento úzus přesunul na konstanty. A dneska je to opět trochu jinde.
-
Vendor lock-in.
-
hele to by mohlo byt zajimave:
int 8 bitu
Int 16 bitu
INt 32 bitu
INT 64 bitu
-
mate radsi franta_pepa_jednicka nebo frantaPepaJednicka nebo snad FrantaPepaJednicka.
pro nejvetsi frajery frAnTa_PepA_JeDNIcka :-)
-
typedef int INT;
typedef LONG HRESULT;
Jestli tohle někomu přináší větší srozumitelnost tak asi bere nějaké drogy. Já bych tohle nevymyslel ani se 4 pivama.
Tak tohle už není maďarská notace, tohle se dělalo kvůli snazší přenositelnosti/upravitelnosti. Když jsi se rozhodl upravit typ, stačilo to udělat na jednom místě.
-
mate radsi franta_pepa_jednicka nebo frantaPepaJednicka nebo snad FrantaPepaJednicka.
pro nejvetsi frajery frAnTa_PepA_JeDNIcka :-)
To prvni pouzivam na promenne, to druhe na funkce, to treti na tridy a v trochu umirnenejsi verzi to ctvrte u jazyku, ktere nemaji jmenne prostory.
-
To vzniklo dokonce uz v 80. letech, kdy jeste neexistovaly poradne IDE a kod se psal v textovem editoru a pokud byly metody a kod slozitejsi, tak to umoznovalo se vyznat v typu. Navic to ti programatori jeste blbe pochopili, nemelo se to pouzivat pro jednoduche typy, ale rozlezlo se to vsude. Jsou o tom clanky na webu.
Dnes je to historie a nemelo by se to pouzivat. Typ mne ukazuje IDE.
-
To vzniklo dokonce uz v 80. letech, kdy jeste neexistovaly poradne IDE a kod se psal v textovem editoru a pokud byly metody a kod slozitejsi, tak to umoznovalo se vyznat v typu. Navic to ti programatori jeste blbe pochopili, nemelo se to pouzivat pro jednoduche typy, ale rozlezlo se to vsude. Jsou o tom clanky na webu.
Dnes je to historie a nemelo by se to pouzivat. Typ mne ukazuje IDE.
Ne každý používá ide a také je rozdíl mít možnost se dotázat jednotlivě na typ v ide a druhá vidět u všech proměnných ten typ v algoritmu současně. Ve složitějších algoritmech se spoustou proměnných to je stále dobrá pomůcka pro lepší srozumitelnost kódu.
Kvalitní název proměnné je k nezaplacení. Lze to používat i více abstraktně, než jen na datové typy. Třeba já jsem si zvykl v JS dávat předponu el u všech proměnných, které odkazují na nějaký html element a els u proměnných, které odkazují na jejich kolekci.
Je to užitečné navzdory tomu, že si v debuggeru mohu na každou proměnnou kliknout a podívat se co obsahuje. Konec konců, můžu tam mít chybu a může obsahovat i něco jiného než má, takže je to naopak nápověda k tomu, že je někde něco špatně. Navíc, když ten debugger v prohlížeči zrovna neběží, neukazuje nic, přesto v něm můžeš koukat do zdrojáků. Takže já to za překonané a 'nemělo by se to používat' nepovažuji.
U vlastního kódu si to člověk udělá po svém, ale když pak trasuješ kód nějaké knihovny a chceš si ji třeba přizpůsobit, je to k nezaplacení. Viz obtížnost pochopit minifikovaný javascript.
-
Navic to ti programatori jeste blbe pochopili, nemelo se to pouzivat pro jednoduche typy, ale rozlezlo se to vsude.
Dnes je to historie a nemelo by se to pouzivat. Typ mne ukazuje IDE.
Je to ještě horší, nemělo se to vůbec používat na datové typy. Mělo se to používat na kontext. Například sText vs. usText (safe vs. unsafe).
Doporučuju přečíst https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/
Můžete přeskočit pár kapitol a začít u "I'm hungary".
Ne každý používá ide a také je rozdíl mít možnost se dotázat jednotlivě na typ v ide a druhá vidět u všech proměnných ten typ v algoritmu současně. Ve složitějších algoritmech se spoustou proměnných to je stále dobrá pomůcka pro lepší srozumitelnost kódu.
Kvalitní název proměnné je k nezaplacení. Lze to používat i více abstraktně, než jen na datové typy. Třeba já jsem si zvykl v JS dávat předponu el u všech proměnných, které odkazují na nějaký html element a els u proměnných, které odkazují na jejich kolekci.
Kvalitní název proměnné je důležitý, ale datový typ na každém řádku C/C++ opravdu nepotřebujete. Ta prefixová (maďarská notace) idea vznikla v týmu pro Word a používala se pro kontextové rozlišení proměnných. Typicky totiž pracovali se souřadnicemi v několika soustavách (okno, dokument, obrazovka).
A "System hungarian" notace to nejenže začala používat pro jednoduché typy, ale navíc zmizel i ten kontext! Takže to bylo zhoršení po všech stránkách.
V Javascriptu to může pořád být užitečné, protože je to hodně dynamický jazyk. Ale univerzálně to neplatí. A tazatel se ptá právě na použití v kontextu Windows, kde tu ideu někdo velice špatně pochopil.
-
Ne každý používá ide a také je rozdíl mít možnost se dotázat jednotlivě na typ v ide a druhá vidět u všech proměnných ten typ v algoritmu současně. Ve složitějších algoritmech se spoustou proměnných to je stále dobrá pomůcka pro lepší srozumitelnost kódu.
Kvalitní název proměnné je k nezaplacení. Lze to používat i více abstraktně, než jen na datové typy. Třeba já jsem si zvykl v JS dávat předponu el u všech proměnných, které odkazují na nějaký html element a els u proměnných, které odkazují na jejich kolekci.
Kvalitní název proměnné je důležitý, ale datový typ na každém řádku C/C++ opravdu nepotřebujete. Ta prefixová (maďarská notace) idea vznikla v týmu pro Word a používala se pro kontextové rozlišení proměnných. Typicky totiž pracovali se souřadnicemi v několika soustavách (okno, dokument, obrazovka).
A "System hungarian" notace to nejenže začala používat pro jednoduché typy, ale navíc zmizel i ten kontext! Takže to bylo zhoršení po všech stránkách.
V Javascriptu to může pořád být užitečné, protože je to hodně dynamický jazyk. Ale univerzálně to neplatí. A tazatel se ptá právě na použití v kontextu Windows, kde tu ideu někdo velice špatně pochopil.
Také záleží na dalších okolnostech. Ve funkci, která má pár řádků a krátkou životnost je to jiné, než u proměnných, které mají dlouhou životnost a objevují se na různých místech programu. Rozlišování datových typů se hodí hlavně tam, kde pracuji se stejným obsahem, ale s různými datovými typy. Jr to potřeba brát s rozumem, používat to tam, kde to má přínos. Ale chápu potřebu molocha, jako je microsoft, že se snaží mít jednotné api napříč projektem, na kterém pracují stovky lidí. Tam je třeba disciplinovanost, byť je občas ne zcela smyslná. Kdo si vzpomíná na rané verze php, ten ví, tam to byl pěkný kočkopes, jak v názvech, tak třeba v pořadí parametrů. A výsledkem byla zbytečně vyšší chybovost.
-
Také záleží na dalších okolnostech. Ve funkci, která má pár řádků a krátkou životnost je to jiné, než u proměnných, které mají dlouhou životnost a objevují se na různých místech programu. Rozlišování datových typů se hodí hlavně tam, kde pracuji se stejným obsahem, ale s různými datovými typy. Jr to potřeba brát s rozumem, používat to tam, kde to má přínos. Ale chápu potřebu molocha, jako je microsoft, že se snaží mít jednotné api napříč projektem, na kterém pracují stovky lidí. Tam je třeba disciplinovanost, byť je občas ne zcela smyslná. Kdo si vzpomíná na rané verze php, ten ví, tam to byl pěkný kočkopes, jak v názvech, tak třeba v pořadí parametrů. A výsledkem byla zbytečně vyšší chybovost.
Ano, jelikož, jak jsi sám přiznal, všechno prasíš do jednoho dlouhého souboru, proměnné mají dlouhou životnost a (objevují se?) na různých místech programu, potřebuješ tyhle obezličky. Asi by stálo za to se zamyslet a namísto maďarské notace přestat prasit. Kromě jiného by mohlo pomoci i v tom Vimu používat pluginy, které drží kontext - co třeba na Rootu nedávno recenzované Kite, Kite?
-
windows.h je hnusný smrdutý výhonek pekla. A ta maďarská notace je ještě ta lepší část. Chápu historické důvody, které to způsobily, ale stejně to jen na zlost.
Proč se mi sakra moje metoda neslinkuje? Aha, protože se jmenuje "CreateFile" a někde se mi tam dostalo windows.h.
Proč mi sakra překladač vyhazuje takovou nesrozumitelnou chybu? Aha, já pojmenoval proměnnou "far" a někde se mi tam dostalo windows.h.
windows.h je dobré mít nepropustně zabalené a oddělené od zbytku kódu. A při údržbě doporučuju gumové rukavice a dvoumetrové bidlo. :D
A pokud to nejde, tak neincludovat windows.h přímo, ale přes vlastní header který #undefne všechny ty pasti.
-
Také záleží na dalších okolnostech. Ve funkci, která má pár řádků a krátkou životnost je to jiné, než u proměnných, které mají dlouhou životnost a objevují se na různých místech programu. Rozlišování datových typů se hodí hlavně tam, kde pracuji se stejným obsahem, ale s různými datovými typy. Jr to potřeba brát s rozumem, používat to tam, kde to má přínos. Ale chápu potřebu molocha, jako je microsoft, že se snaží mít jednotné api napříč projektem, na kterém pracují stovky lidí. Tam je třeba disciplinovanost, byť je občas ne zcela smyslná. Kdo si vzpomíná na rané verze php, ten ví, tam to byl pěkný kočkopes, jak v názvech, tak třeba v pořadí parametrů. A výsledkem byla zbytečně vyšší chybovost.
Ano, jelikož, jak jsi sám přiznal, všechno prasíš do jednoho dlouhého souboru, proměnné mají dlouhou životnost a (objevují se?) na různých místech programu, potřebuješ tyhle obezličky. Asi by stálo za to se zamyslet a namísto maďarské notace přestat prasit. Kromě jiného by mohlo pomoci i v tom Vimu používat pluginy, které drží kontext - co třeba na Rootu nedávno recenzované Kite, Kite?
Tohle prasení dělám jen u svých soukromých projektů a životnost proměnné přece nesouvisí s tím, jestli mám 50 tříd napsaný v jednom nebo v 50 souborech. Jestli si myslíš, že jsem nějaký Kit, tak jsi vedle. Dobře nazvaná proměnná není obezlička, to je základ dobrého programování. Dobrý název je samopopisný a nahradí ti půlku dokumentace. Někdy je těžké na něj přijít. Lidem kterým opravuji kódy se mnohdy rozsvítí jen tím, že jim ty proměnné přejmenuji.
-
Naprosto nic nemam proti vystiznym identifikatorum, naopak! Ale identifikator ma popisovat obsah a ne datovy typ. Ten by mel jazyk nebo tooling resit extra. Jestli si pises el namisto element, nemam s tim problem, ale jakmile si nekdo pise predponu i jako integer nebo s jako string, je za tim zrejme neco podivneho.
-
Naprosto nic nemam proti vystiznym identifikatorum, naopak! Ale identifikator ma popisovat obsah a ne datovy typ. Ten by mel jazyk nebo tooling resit extra. Jestli si pises el namisto element, nemam s tim problem, ale jakmile si nekdo pise predponu i jako integer nebo s jako string, je za tim zrejme neco podivneho.
Tak protoze ja v Pythonu cpu do jedne promenne ruzne typy, tak to nerozlisuju
cislo = '1'
cislo = int(cislo)
Ale kdybych potreboval z nejakeho duvodu pracovat s obema formami soucasne, tak si je pravdepodobne rozlisim na iCislo a na sCislo.
-
Naprosto nic nemam proti vystiznym identifikatorum, naopak! Ale identifikator ma popisovat obsah a ne datovy typ. Ten by mel jazyk nebo tooling resit extra. Jestli si pises el namisto element, nemam s tim problem, ale jakmile si nekdo pise predponu i jako integer nebo s jako string, je za tim zrejme neco podivneho.
Já bych tady přidal, že ten datový typ by měl co nejvíc vypovídat o tom obsahu. Pokud můžu různé věci reprezentovat různými typy, tak je to jen dobře. Nejde to samozřejmě vždycky, ale věci co mi hlídá překladač si nemusím hlídat já.
Nechat předpony pro věci, co překladač neohlídá, mi přijde hodně rozumné.
Tak protoze ja v Pythonu cpu do jedne promenne ruzne typy, tak to nerozlisuju
cislo = '1'
cislo = int(cislo)
No tak tahle recyklace mi přijde jako zbytečný dodatečný nápor na hlavu. A to nejenom int+string ale třeba i recyklovat jednu proměnnou pro několik logicky různých intů. Už mi pro přemýšlení o obsahu nestačí jméno, ale musím tam zahrnout i místo.
Nevím jak v pythonu, ale moderní optimalizující překladače zlikvidují jakoukoliv takovouhle recyklaci jako jednu z prvních věcí, protože v SSA formě dostane každé přiřazení svou unikátní proměnnou.
-
cislo = '1'
cislo = int(cislo)
No tak tahle recyklace mi přijde jako zbytečný dodatečný nápor na hlavu. A to nejenom int+string ale třeba i recyklovat jednu proměnnou pro několik logicky různých intů. Už mi pro přemýšlení o obsahu nestačí jméno, ale musím tam zahrnout i místo.
Nevím jak v pythonu, ale moderní optimalizující překladače zlikvidují jakoukoliv takovouhle recyklaci jako jednu z prvních věcí, protože v SSA formě dostane každé přiřazení svou unikátní proměnnou.
[/quote]
Neni to zadny napor na hlavu, promenna je ukazatel na data a jedna se o stejna data, jen v jine forme. Jake optimalizace si dela prekladac me prakticky nezajima. Zkus to vnimat jako prechod na vyssi formu abstrakce nesvazanou s datovym typem. A je to abstrakce pro programatora, nikoliv pro prekladac. Vyvoj v it jde smerem, ze se stroje stale vic prizpusobuji lidskemu mysleni. Viz jak to zacalo, programovani ve strojovem kodu.
-
Neni to zadny napor na hlavu, promenna je ukazatel na data a jedna se o stejna data, jen v jine forme. Jake optimalizace si dela prekladac me prakticky nezajima. Zkus to vnimat jako prechod na vyssi formu abstrakce nesvazanou s datovym typem. A je to abstrakce pro programatora, nikoliv pro prekladac. Vyvoj v it jde smerem, ze se stroje stale vic prizpusobuji lidskemu mysleni. Viz jak to zacalo, programovani ve strojovem kodu.
Ale ona to úplně stejná data nejsou. V podobě intu to má výrazně menší stavový prostor než ve formě stringu.
Pokud je to string na vstupu, pak je ten stavový prostor větší o nejrůznější chybný nebo útočný binec. Pokud ten rozdíl odignoruju, mám bezpečnostní díru.
Pokud je to string na výstupu, pak je ten stavový prostor větší o to, jak ten int chci vypsat. U intu těch možností moc není, ale u jiných typů ten stavový prostor bobtná dost zásadně.
Kdyby opravdu nezáleželo na datovém typu, tak to může zůstat jako int (nebo string). Ale ono je to z nějakého důvodu nutné převést. A ten důvod z té abstrakce prosakuje ven (leaky abstraction). Typ (ve formě množiny hodnot, které můžu čekat) tam stále je.
-
A ještě jedna věc. Ta moje připomínka vlastně není primárně o typech. Proto jsem tam psal o těch různých intech. Proměnná není primárně ukazatel. To už je implementační detail. Primární je lidsky čitelné jméno. A díky té recyklaci už ze jména není vidět rozdíl mezi stavy před a po. A ten rozdíl důležitý je, jinak bys tu transformaci nedělal.
-
typedef int INT;
typedef LONG HRESULT;
Jestli tohle někomu přináší větší srozumitelnost tak asi bere nějaké drogy. Já bych tohle nevymyslel ani se 4 pivama.
Ten INT takto vytrhnutý z kontextu nemá zmysel, ani ho dnes nik nepoužíva okrem starých API. Tie názvy majú svoj význam, len si treba pozrieť aj aké iné typy sú takto definované a uvedomiť si kedy vznikli (možno 40 rokov dozadu). Napr. LPWORD sa predsa len lepšie píše ako (unsigned short * far). Nie len že ešte neexistovali IDE ako dnes, ale bolo to v časoch 16 bit architektúry keď pointre mohli byť far (segment+adresa) a near (adresa 16 bit). Tiež sa už myslelo na prechod na 32 bit a napr. typy ako WPARAM a pod. boli závislé od toho, či sa kompilovala 16 alebo 32 bit aplikácia. Navyše každý kompiler mohol mať rôzne veľkosti typov int, short, atď (ešte neexistovali typy ako int32_t).
HRESULT je zas typ pre štandardné chybové kódy, náhodou o veľkosti LONG. Keď vidím, že funkcia vracia HRESULT, tak hneď viem ktoré bity čo znamenajú a ktorými makrami môžem ten výsledok spracovať. Keby funkcia vracala int, tak to nenesie žiadnu informáciu ako s výsledkom pracovať a treba hľadať v dokumentácii či to je nejaký kód chyby, alebo počet, alebo niečo iné.
-
Neni to zadny napor na hlavu, promenna je ukazatel na data a jedna se o stejna data, jen v jine forme. Jake optimalizace si dela prekladac me prakticky nezajima. Zkus to vnimat jako prechod na vyssi formu abstrakce nesvazanou s datovym typem. A je to abstrakce pro programatora, nikoliv pro prekladac. Vyvoj v it jde smerem, ze se stroje stale vic prizpusobuji lidskemu mysleni. Viz jak to zacalo, programovani ve strojovem kodu.
Ale ona to úplně stejná data nejsou. V podobě intu to má výrazně menší stavový prostor než ve formě stringu.
Pokud je to string na vstupu, pak je ten stavový prostor větší o nejrůznější chybný nebo útočný binec. Pokud ten rozdíl odignoruju, mám bezpečnostní díru.
Pokud je to string na výstupu, pak je ten stavový prostor větší o to, jak ten int chci vypsat. U intu těch možností moc není, ale u jiných typů ten stavový prostor bobtná dost zásadně.
Kdyby opravdu nezáleželo na datovém typu, tak to může zůstat jako int (nebo string). Ale ono je to z nějakého důvodu nutné převést. A ten důvod z té abstrakce prosakuje ven (leaky abstraction). Typ (ve formě množiny hodnot, které můžu čekat) tam stále je.
Technicky, z pohledu ulozeni v pameti, stejné nejsou. Vyznamove, po zanedbani zpusobu ulozeni v pameti, ale jsou. Proto jsem psal, at se to pokusis vnimat jako vyssi abstrakci. Jak jsem psal, v uvedenem pripade to, jako programator, nepotrebuji rozlisovat, proto to nerozlisuji. Kdybych to potreboval rozlisit, tak prave a jen z duvodu jinych typu a pak pouziju zminenou madarskou notaci.
V jazycích jako PHP to prevadet nepotrebujes, tam se to prevadi implicitne podle potreby. V pythonu to prevest potrebujes, ale ne vzdy to potrebujes rozlisovat na urovni promenych a mit pro kazdy typ jinou.
-
A ještě jedna věc. Ta moje připomínka vlastně není primárně o typech. Proto jsem tam psal o těch různých intech. Proměnná není primárně ukazatel. To už je implementační detail. Primární je lidsky čitelné jméno. A díky té recyklaci už ze jména není vidět rozdíl mezi stavy před a po. A ten rozdíl důležitý je, jinak bys tu transformaci nedělal.
V pythonu je promenna vzdycky ukazatel. Je to pojmenovany odkaz do pameti na prislusny datovy objekt. Ne, neni pro me dulezity a davam to najevo tim pojmenovanim. Je to jako pouzivani pomocne promenne tmp ve statickem jazyku, kde nemas potrebu ji nejak specificky pojmenovat, akorat tam musis respektovat datovy typ, v dynamickem jazyku to je jednodussi. Duvody ktere uvadis jsou formalni, byrokraticke, pragmaticky vzato ale v uvedenem pripade zcela zbytecne.
-
typedef int INT;
typedef LONG HRESULT;
Jestli tohle někomu přináší větší srozumitelnost tak asi bere nějaké drogy. Já bych tohle nevymyslel ani se 4 pivama.
Ten INT takto vytrhnutý z kontextu nemá zmysel, ani ho dnes nik nepoužíva okrem starých API. Tie názvy majú svoj význam, len si treba pozrieť aj aké iné typy sú takto definované a uvedomiť si kedy vznikli (možno 40 rokov dozadu). Napr. LPWORD sa predsa len lepšie píše ako (unsigned short * far). Nie len že ešte neexistovali IDE ako dnes, ale bolo to v časoch 16 bit architektúry keď pointre mohli byť far (segment+adresa) a near (adresa 16 bit). Tiež sa už myslelo na prechod na 32 bit a napr. typy ako WPARAM a pod. boli závislé od toho, či sa kompilovala 16 alebo 32 bit aplikácia. Navyše každý kompiler mohol mať rôzne veľkosti typov int, short, atď (ešte neexistovali typy ako int32_t).
HRESULT je zas typ pre štandardné chybové kódy, náhodou o veľkosti LONG. Keď vidím, že funkcia vracia HRESULT, tak hneď viem ktoré bity čo znamenajú a ktorými makrami môžem ten výsledok spracovať. Keby funkcia vracala int, tak to nenesie žiadnu informáciu ako s výsledkom pracovať a treba hľadať v dokumentácii či to je nejaký kód chyby, alebo počet, alebo niečo iné.
Presne, typedef se v C pouziva kvuli snadnym zmenam architektury a kvuli semantickemu rozliseni datovych typu.