Dotaz: Alternativa k OpenAL

[Jardík]

Neví někdo o nějaké alternativě k OpenAL, kde nepoužívají vlastní datové typy typu ALuint, ALsizei? V takovém případě mi totiž nikdo neručí za to, že např. ALsizei bude size_t. Nějaká specifikace mi říká non-negative 32-bit binary integer size, což je pro mě nevhodné, protože pak nemůžu (bez možných špatných následků, či stupidně zdržující kontrole přetečení) např. použít výsledek operátoru sizeof. Prostě něco, kde používají normální typy (u)intX_t pro typy s pevně danou velikostí a size_t pro velikosti a indexace polí apod.

Odpovědi

[petr_p]

Specifikace je v tomto stejně nejasná jako a protože OpenGL. Mně z toho vyplývá, že je tím myšleno int32_t s omezením, že nesmí nést zápornou hodnotu.

[Jardík]

Ano, to z toho taky chápu a je to jedna z věcí, co mi právě tom OpenAL vadí. Kromě toho, že si prostě musí vytvářet nové typy a nutí vás si znepřehledňovat program a řešit věci typu fread() mi vrátí počet bytů jako size_t, já v kódu musím ošetřovat, jestli sizeof(ALsizei) je menší nebo větší, než velikost size_t, přetypovávat, ošetřovat přetečení kvůli znaménku, ... kód je pak hnusný, nepřehledný a je tu možnost vzniku spousty nechtěných chyb (a v praxi se opravdu takové chyby vyskytují, neošetřené a je "náhoda", že to všem funguje, protože to nevyužívají "naplno"). Dále mě to nutí používat (kvůli přehlednosti) dané typy i ve zbytku mé aplikace, nebo upravovat již existující části na dané typy a omezuje to velikost zpracovávaných dat apod. Tohle mi vadí.

[petr_p]

Z pohledu uživatele knihovny to je hnus. To uznávám. Z pohledu definice ABI knihovny je ale důležité mít přesnou specifikaci.

Obávám se, že jakýkoliv rozumný datový formát se gumovým typům (int, size_t) zdaleka vyhne.

Když už jste nakousl fread(), tak ta je ještě příčetná v tom smyslu, že vrací jen kladné hodnoty. Jsou funkce, které při chybě vrací size_t(-1).

Problém se často řeší při překladu. Otestuje se, zda-li jsou typy kompatibilní, když ne, překlad selže. V lepším případě se přetypování nahradí makrem, které pro kompatibilní typy nic nedělá, pro nekompatiblní vloží test na rozsah. (Pokročilé překladače dokáží zbytečné testy na rozsah vyoptimalizovat pryč.)

Jinak souhlasím, že tyto chyby se často neřeší a pak vyplavou v nejhorší čas. Třeba v poslední verzi pcre se přetypovává ukazatel z long int na int. Což fungovalo, dokud jsme se nepokusili knihovnu přeložit na big endian stroji. Pak se začala dít kouzla, jako segfault kvůli vyčerpání zásobníku :)

[Jardík]

Obávám se, že jakýkoliv rozumný datový formát se gumovým typům (int, size_t) zdaleka vyhne.

Pokud se jedná o formát nějakého typu souboru, či něco přenášeného přes síť, tak ano, souhlasím. Ale pokud má knihovna možnost pracovat s pamětí (např. u OpenAL přehrát zvuk, co je v paměti), tak by pro určení velikosti měli k tomu použít příslušný typ (v tomhle případě jednoznačně size_t, který je přesně k tomu určen). Navíc co nezpůsobí žádné nekompatibility, protože knihovna se stejně pro novou architekturu musí přeložit, stejně jako program ji využívající. Ale asi se nemá cenu hádat. Asi prostě vezmu zdroják OpenAL, trochu o upravím a hold to nebudu vydávat za implementaci OpenAL, ale pojmenuju to nějak.

Jsou funkce, které při chybě vrací size_t(-1).

Tak to ale přece není záporná hodnota ... size_t je definovaný jako neznaménkový typ.

Jinak koukal jsem na wikipedii a tam se píše, že OpenAL 1.0 vyšlo v roce 2000, nevidím problém, proč nemohli v tomto roce použít (u)intX_t či size_t, v tu dobu to byly standardem C99 definované typy ... a size_t už v C89