To je naprosto v pořádku, že tam ty typy jsou. Jsou místa, kde je třeba mít pevně daný typ, například při serializaci. Problém Windows world a jejich developerů je, že je používají naprosto špatně, i v místech, kde mají použít "logický" typedef (off_t, size_t atd). Například DWORD WINAPI GetFileSize(_In_ HANDLE hFile, _Out_opt_ LPDWORD lpFileSizeHigh);, zatímco POSIX má jednoduše off_t. A chování té funkce je tedy lahůdka, nepoužívám ostrá slova, ale tohle musel designovat opravdu blbec posedlý DWORDy: Note that if the return value is INVALID_FILE_SIZE (0xffffffff), an application must call GetLastError to determine whether the function has succeeded or failed. The reason the function may appear to fail when it has not is that lpFileSizeHigh could be non-NULL or the file size could be 0xffffffff. In this case, GetLastError will return NO_ERROR (0) upon success.
Jak už tu padlo, GetFileSize je staré API, a bylo před mnoha lety nahrazeno pomocí GetFileSizeEx. Nakonec je to uvedené i v popisu funkce.
Dále zjištění velikosti souboru na Unixech probíhá pomocí volání stat nebo stat64, výsledek inteligentně dostanete struktuře, a ta obsahuje member, který má typ off_t nebo off64_t. No a jestli vám přijde dobrý nápad mít na file offset vlastní datový typ off_t, který je "signed integer... no narrower than int", a pak ještě off64_t, který je také signed a také no narrower than int, ale navíc je na 32-bitových systémech 64-bitový... tak k tomu asi nemám komentář. BTW o kvalitě dokumentace glibc vs MSDN asi nemá smysl psát.
Díky za link na Windows Data Types, to je taky dílo:
DWORDLONG - A 64-bit unsigned integer. The range is 0 through 18446744073709551615 decimal.
DWORD32 - A 32-bit unsigned integer.
DWORD64 - A 64-bit unsigned integer.
DWORD byl původně double word, resp 32-bit uint, což je jako platform independent samo o sobě brain-damaged, ale vem to peklo. Tady z pevně daného typu udělají suffixem jiný typ přesto, že logické jméno reflektuje ten starý pevný 32-bit. To byl jen příklad, v rámci toho linku se dají najít mnoho dalších neméně "povedených"
Qt a Glib oproti tomu mají jasné a výstižné názvy, ze kterých je jasně viditelný smysl, použití a velikost.
DWORD byl původně double word, a postupem času se z něj stal unsigned int, by default 32-bitový. To že se z něj sufixem 64 udělá 64-bitový typ mi připadá poměrně logické. Jinak použití typů bez definované šířky (jak je nešťastným zvykem v definici jazyka C) považuji za příčinu většiny problémů v portování na 64-bitové platformy.
Qt a Glib jsou poměrně high level knihovny. Win32 je API z roku 1993, a když srovnáte .NET Framework nebo WinRT s Qt nebo Glib, tak na tom MS není s datovými typy špatně. Hlavně je na tom ale velmi dobře s funkcionalitou a dokumentací.
Mimochodem u těch platform independent typů (size_t, off_t, uintptr_t, time_t a další) jste viděl, že portaci velkých projektů nijak nepomohly, a například u OpenOffice to zdaleka nebylo "jen o zkompilování a spuštění". Uvědomte si, že řada starších aplikací například serializuje objekty do binárního blobu, a je tak dělaná mimo jiné většina souborových formátů uvedených před XML. Všechny tyhle věci se vám při změně datových typů zhroutí jako domeček z karet. OO sice používal souborový formát založený na XML, ale kupodivu při portu na x86-64 dospěl i do stádia, kdy byl schopný číst binární dokumenty MS Office, ale ne OOXML (vizte prezentaci).
35 Odpovědí
16494 Zhlédnutí