abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 23:55 | Komunita

    Ubuntu 26.04 LTS bude (𝕏) Resolute Raccoon (rezolutní mýval).

    Ladislav Hagara | Komentářů: 0
    včera 21:00 | Nová verze

    Netwide Assembler (NASM) byl vydán v nové major verzi 3.00. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.

    Ladislav Hagara | Komentářů: 0
    včera 20:11 | Komunita

    Linuxová distribuce Frugalware (Wikipedie) ke konci roku 2025 oficiálně končí.

    Ladislav Hagara | Komentářů: 0
    včera 17:22 | Nová verze

    Byla vydána nová verze 3.0.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP bude brzy k dispozici také na Flathubu.

    Ladislav Hagara | Komentářů: 0
    včera 16:11 | IT novinky

    Americký výrobce čipů AMD uzavřel s americkou společností OpenAI smlouvu na několikaleté dodávky vyspělých mikročipů pro umělou inteligenci (AI). Součástí dohody je i předkupní právo OpenAI na přibližně desetiprocentní podíl v AMD.

    Ladislav Hagara | Komentářů: 1
    včera 12:22 | Nová verze Ladislav Hagara | Komentářů: 0
    5.10. 20:00 | Komunita

    Byly zpracovány a na YouTube zveřejněny videozáznamy z konference LinuxDays 2025.

    Ladislav Hagara | Komentářů: 0
    4.10. 15:22 | IT novinky

    Na konferenci LinuxDays 2025 byl oficiálně představen nový router Turris Omnia NG.

    Ladislav Hagara | Komentářů: 34
    4.10. 05:22 | Komunita

    Přímý přenos (YouTube) z konference LinuxDays 2025, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.

    Ladislav Hagara | Komentářů: 16
    3.10. 22:44 | IT novinky

    V únoru loňského roku Úřad pro ochranu osobních údajů pravomocně uložil společnosti Avast Software pokutu 351 mil. Kč za porušení GDPR. Městský soud v Praze tuto pokutu na úterním jednání zrušil. Potvrdil ale, že společnost Avast porušila zákon, když skrze svůj zdarma dostupný antivirový program sledovala, které weby jeho uživatelé navštěvují, a tyto informace předávala dceřiné společnosti Jumpshot. Úřad pro ochranu osobních údajů

    … více »
    Ladislav Hagara | Komentářů: 10
    Jaké řešení používáte k vývoji / práci?
     (38%)
     (45%)
     (15%)
     (17%)
     (22%)
     (15%)
     (18%)
     (16%)
     (15%)
    Celkem 181 hlasů
     Komentářů: 12, poslední 4.10. 20:35
    Rozcestník

    Dotaz: Alternativa k OpenAL

    Jardík avatar 11.1.2011 18:25 Jardík | skóre: 40 | blog: jarda_bloguje
    Alternativa k OpenAL
    Přečteno: 395×
    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.
    Věřím v jednoho Boha.

    Odpovědi

    11.1.2011 21:35 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Alternativa k OpenAL

    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 avatar 11.1.2011 22:30 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Alternativa k OpenAL
    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í.
    Věřím v jednoho Boha.
    12.1.2011 08:20 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Alternativa k OpenAL

    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 avatar 12.1.2011 12:20 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Alternativa k OpenAL
    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

    Věřím v jednoho Boha.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.