LZHAM 1.0

Rich Geldreich, bývalý vývojář Valve, vydal první stabilní verzi 1.0 bezeztrátového kompresního algoritmu a knihovny LZHAM (GitHub). Komprese s LZHAM je srovnatelná s LZMA, dekomprese je ale 1,5 až 8 krát rychlejší. Rich Geldreich pracuje na LZHAM již více než 3 roky. Předchozí vývoj probíhal na Google Code. [Phoronix]

26.1.2015 01:01 | Ladislav Hagara | Zajímavý software

Komentáře

[Jardík]

Voni se nikdy nenaučej programovat:

#ifndef __LZHAM_H__

Prasárna. Už by letěl. Má tam dvě podtržítka.

typedef unsigned char lzham_uint8;
typedef signed int lzham_int32;
typedef unsigned int lzham_uint32;

Jako proč? Neznaj typ uintN_t? A od kdy musí být char osmibitovej na všech platformách? Správně je samozřejmě použít typy uintN_least_t nebo uintN_fast_t, podle toho, jestli je potřeba šetřit s pamětí, nebo být rychlý. Tyto typy taky mají garantovanou existenci, narozdíl od uintN_t. Každopádně si ale pro výhru musíme definovat své typy, aby když uživatel pracuje s další knihovnou, co používá třeba uint32_t, musel jak kokot procpat svůj kód (static) assertama, jestli jsou typy schodné, nebo různejma krávovinama typu kontroli přetečení. Protože není bezpečné jen tak předpokládat, že nějaký lzham_uint32 bude vždy 32bit jako nějaký uint32_t. I když to má 32 v názvu, neříká to vůbec nic o tom, žě autor knihovny takto neoznačuje 64bit číslo, když už je to takový prase.

... dál zdroják nečtu, zvednul se mi kýbl ...

[Marián Kyral]

Koukám, že teorie by ti šla

[mankind_boost_reloaded]

Taky jeden "programátor"?

[AlYoSHA]

...a spravodlivo rozhnevany :)

[Jardík]

Však já to vždycky říkal. Keců plná huba, ale naprogramovat nic nejsem schopnej, protože mi každá knihovna přijde rozbitá, nebo něco nemožné (např. přístup k CD mechanice v linuxu ala moje BurnApp). A když něco začnu a vypadá to nerozbitě, tak to stejně nedokončím, protože mě to přestane bavit. Ale rejpání, nějak si to nemůžu odpustit. Někdy bych chtěl dohnat Pléšu

[Šangala]

Co vadí na tom zdvojeném podtržítku (krom toho, že to není hezké)?

uintN_least_t, uintN_fast_t je jen o tak maličký krůček jiné na veřejném rozhraní (interně je to putna), že je zbytečné o tom hovořit a prakticky mi naopak přijde jako vyšší záruka pevně definovaný typ konkrétní knihovnou, když už to teda není přímo uintN_t, než leasty a fasty, které se mohou dle platformy měnit.

PS: unsigned char lzham_uint8; je to samé jako u uint8_least_t lzham_uint8;, tak bych se tím vůbec nestresoval…

[Michal Kubeček]

Co vadí na tom zdvojeném podtržítku (krom toho, že to není hezké)?

Identifikátory začínající dvěma podtržítky jsou podle normy rezervované.

[Šangala]

Něco takového jsem tušil… - Dík.

[jojo]

normy jsou od toho, aby se prekracovly. copak te neucili plnit plan na 110% ?

[Šangala]

Učili mě, že můžu překračovat maximálně na 120 % (víc bych to pos..l sobě a všem ostatním).

[:::]

Myslim ze kdyz to jmeno udelas dostatecne unikatni, jako treba v tomhle pripade, tak zadna kolize nehrozi.

Kdybys pouzil jenom LZHAM_H, nebo dokonce lzham_h, tak je podle me mnohem vetsi sance, ze to bude s necim kolidovat - ne s nejakym internim makrem prekladace, ale s uzivatelskym kodem...

[Bedňa]

Osobne používam názvy premenných tak aby aj bez komentára bolo jasné o čo ide. Pokiaľ používaš inteligentné IDE, tak na kolíziu prídeš aj sám.

[aaaaa]

Clovek pouzivajuci v kode nieco so suffixom _H si koleduje aj tak. A ked je to take prasa, tak ho nezastavia ani dve podtrzitka.

[:::]

Urcite nesouhlasim s tim ze kdo pouzije suffix _h je prase... Je rozdil mezi varejnyma vecma, kde je lepsi delsi popisny jmeno, a lokalnima, kde je casto lepsi strucnost.

Problem maker je ze ti zaneradi namespace na vsech urovnich, proto kdyz uz se nahodou musi pouzivat, tak by meli mit co nejhnusnejsi jmena...

[Jardík]

Nejen začínající. Ať už jsou dvě podtržítka na jakémkoliv místě, třeba uprostřed, je to rezervováno. Proto je lepší místo blbin __MUJ_HEADER_H__ psát třeba MUJ_HEADER_H_INLUDED (pokud mu z nějakého důvodu nestačí MUJ_HEADER_H), ale to je pro někoho hold moc zdlouhavé a tak radši uděláme dvě podtržítka na konci a na začátku.

[kralyk z abclinuxu]

Docela rozumný pravidla pro include guards má google...

[Šangala]

K tomu jsem se taky dopracoval ale mám to:

INC_prj_cesta_filename_H_year_or_something_else

a #endif okomentovaný mezi /* */

všechna makra mám prjM_jmeno všechny „macro-konstanty“ prjD_jmeno a makra specifické dané třídě/namespace mají prj?_namespace_jmenoTridy_jmenoMacra a super se mi v tom pak orientuje (pomocné makro se může jmenovat třeba jen XY, ale v rámci files-u ho na závěr undef-uju) .

[Michal Kubeček]

Ať už jsou dvě podtržítka na jakémkoliv místě, třeba uprostřed, je to rezervováno.

Kde přesně se tohle říká? Já v ISO C99 nic takového nevidím.

[Jardík]

C++11, poslední draft, v předešlém standardu je to taky

17.6.4.3.2 Global names [global.names]

1 Certain sets of names and function signatures are always reserved to the implementation:

• Each name that contains a double underscore or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
• Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace

V C99 a C11 to není, tam se nesmí jen začínat, pravda. Ale z hlavičkových souborů, kde je

#ifdef __cplusplus
extern "C" {
#endif

předpokládám, že se jedná o hlavičkový soubor C i C++.

[Šangala]

No ten druhý bod je bezva, aspoň nebudou vymizí ty lokální proměnné tříd začínající ‚_‘, které nemám rád…

[:::]

ten druhy bod plati jen v globalnim namespace

btw. jak pojmenovavas promenne trid, kdyz ne s podtrzitkem ?

[Šangala]

Z mého vlastního codestylu by byl asi málokdo šťastný, ale mám ho definovaný :).
Bez podtržítka (, které tam „nemám rád“ - je matoucí a považuji ho za špatný nápad až tohoto tisíciletí) ... každé použití jedu přes this−> (ale i tak syntax highlighting toto lokální a členské proměnné rozliší jasně) ;).
Ale hlavně třídy začínám malým písmenem, protože dávám prefix co je to zač iMyInterface, cMyClass, aMyAbstractClass, MyStaticClass atd.

[kralyk z abclinuxu]

btw. jak pojmenovavas promenne trid, kdyz ne s podtrzitkem ?

Proč by se vůbec měly proměnné tříd pojmenovávat s podtržítkem?

[Šangala]

Protože je to moderní (ale je to děsný zvyk)

[:::]

Ja nemam rad c++ access modifikatory (private, protected), protoze je nemozny je obejit. Teda krome uplnyho zakazu (#define private public).

Myslim ze je lepsi udelat vsechno public, a private veci nejak oznacit, treba podtrzitkem, cimz rikam "pouziti na vlastni nebezpeci."

Dobre tenhle pristup shrnuje pythonni slogan "We're all consenting adults here"

[Šangala]

Tak to je fičák nebo totální rezignace…

[Jardík]

Podtržítko můžete používat nadále. Jen nedeklarujte takové fce v globálním namespace. Jako názvy metod ho můžete používat. Jenom po podtžítku použijte malé a nikoliv velké písmeno. Osobně používám m_ prefix pro členské proměnné, co nejsou public, s_ pro statické, g_ pro globální. Asi úchylka, ale vyhovuje mi to, a vím přesně, co je co. Private metody buď s podtržítkem, když by měli stejný název, jako public metody, jinak bez.

Pro 'obejití access modifikátorů' tu máme 'friend'.

[kralyk z abclinuxu]

Aha tak to jo

[ava]

Mě teda přijde, že tohle se týká až jmen při překladu, ne při preprocessingu, takže #define ____FOO____BAR____ je zcela validní, validní není až int ___Foo____bar____ = 42; , a celý tohle obviňování je nepravdivý. Nebo to tak není?

[Bedňa]

#define ____FOO____BAR____ je zcela validní

A ešte to vyzerá krásne

[:::]

Ja myslim ze je to presne naopak - ze tohle omezeni je tam prave hlavne kvuli makrum. Jinak by stacilo ty jmena omezit jenom v globalnim scope, nebo dokonce jenom v std::

Podivej se treba na kod standardni kvihovny. Vsechny interni veci tam zacinaji '__'. Myslim ze je to proto aby to nahodou nejaky makro neprepsalo...

Jinak v tom ze nejaky jmeno technicky vzato rezervovany bych nevidel problem pokud je udelas dostatecne unikatni...

[Jardík]

Podivej se treba na kod standardni kvihovny. Vsechny interni veci tam zacinaji '__'. Myslim ze je to proto aby to nahodou nejaky makro neprepsalo...

Kvůli tomu, ano. Dá se o tom najít spousta článků, proč jsou standardní knihovny psaný tak hnusně s podtržítkama.

[ava]

Hmm, tak me to dokonce donutilo kouknout do standardu C99 (sekce 7.1.3), a asi uz verim, ze to plati i pro preklad, i pro preproces, i kdyz si tim porad nejsem uplne jistej (je to sileny cteni).

Stejne si ale myslim, ze to omezeni je spis kvuli prekladu - podle me ty rezervovany identifikatory interne generuje prekladac pri name mangling, a takto bychom se do nejakeho z nich nahodou mohli trefit.

Prepsat si makro v knihovne - to nevim jestli jde, nehodilo by to nejake "macro already defined" ? Ale je pravda, ze bych asi mohl nadefinovat nejake makro, na ktere se nekde v knihovne dela #ifdef, a tim zmenit chovani...

Koukam, ze Ccko je nekonecnej zdroj kvizu :)

[Marvin]

Prepsat muzes nejenom makro, ale cokoli jinyho. Treba kdyz budu mit v file.h:

int f(int a);

a nekdo pred inkludovanim toho .h nadefinuje makro:

#define a *q

tak preprocesor me zmeni kod v file.h na:

int f(int *q);

S manglovanim neni problem, protoze to jmeno (pokud nedas extern "C") by se zamanglovalo jeste jednou, takze se do niceho netrefis...

[ava]

jj, o tom redefinovani cehokoliv vim.

Ted jsem zkusil dvakrat definovat to same makro, a hodi to jen warning, takze to prelozit skutecne jde, aspon tedy lidmi co nepouzivaji -Werror :)

O tom dvojitem manglingu jsem nevedel, diky za info.

[Petr Ježek]

Přesně tak. Je problém, když tam není podtržítko, pokud je zdvojené, tak to naopak ničemu kromě těch, co zhasínají na počátku rozbřesku, aby ušetřili, nevadí. Tohle v teorii neučí :)

[mankind_boost_reloaded]

"Je problém, když tam není podtržítko"
Proč?

[Šangala]

Proč? Mě lehce znervózňuje i jedno…

[Ivan]

O jake platformy jde konkretne? Podivejte se na OCI knihovnu od Oracle jak to delaji "profesionalove". Pouzivani typu uintN je zarokou, ze vas kod nakonec nebude prenositelny. Velice rychle totiz narazite na kompilator ktery tohle nepodporuje :(. Bohuzel se porad jeste pouzivaji kompilatory z roku raz-dva.

[R]

A to je problem pre ten historicky kompilator tie chybajuce typy zadefinovat?

[Šangala]

Nevím o jakou platformu jde, a nevím přesně na co narážíš (na neexistenci unsigned typů?).

Je docela běžným řešením #ifdef HAVE_STDINT_H… a pokud není stačí je jen dodefinovat.

PS: Jestli se nepletu tak int8_t, int16_t, int32_t, uint8_t, uint16_t, uint32_t jsou povinné v 2001.

[Ivan]

Myslim, ze s tim ma problem i MSVC 2010. A pak jsem se setkal s necim na HP-UXu.

PS: neni problem si to nadefinovat sam, dokonce se na netu da najit "wrapper" s BSD licenci. Problem je se na tyhle uzitecne typy spolehat. Proto si myslim, ze ten kdo to nepouzije neni v prvni rade idiot, ale spis clovek ktery vi co dela a proc to dela.

[luky]

MSVC je nevyvijena sracka, zastavilo se to u C89.

[Šangala]

Jenže na veřejném rozhraní, když použiješ pár knihoven dohromady, tak se z toho zblázníš (na to naráží Jardík), ale když použiješ něco jednotného (intX_t, uintX_t), co je standard a a lze doplnit, tak je to snazší, jinak blbneš s boost::numeric_cast, nebo máš vlastní cast (můj je hnusnější :)), nebo na to kašleš a pak se to někdy začne chovat jako Windows…

[Ivan]

Jo tak to mate pravdu. Urcite by to vsem usetrilo spoustu casu, kdyby se to tak pouzivalo. V praxi jsem se s tim moc nesetkal, asi proto, ze vetsina C/C++ kodu ve kterym jsem se hrabal je starsi.

[kralyk z abclinuxu]

Myslim, ze s tim ma problem i MSVC 2010.

MS se v novějších verzích MSVC (>=2012) konečně uráčil <cstdint> podporovat.

[Ivan]

nojo oni uz maji i std::numeric_limits, akorat to porad jeste neni const_expr takze se to stejne neda moc pouzit.

Ja si vzdycky prectu o nejaky bajecny technologii, tak to pouziju, pak to zkusim prelozit na woknach a nakonec se potupne vratim makrum preprocesoru. Ty jsou sice hnusny ale jako jediny jsou skutecne prenositelny.

[Jardík]

Pokud někdo udělá typedef unsigned int na uint32_t, protože s tím má kompilátor z roku 1990 problém, tak je hovado, pokud si před tím nezkontroluje velikost toho typu. Jenže takový kompilátor samozřejmě neumí ani static assert, a nezná třeba ani UINT_MAX a podobné, které se dají ke kontrole použít. (přestože UINT_MAX tu je snad od 89, ale debilní kompilátor je hold debilní kompilátor).

[pc2005]

Doufám, že to není prošpikováno patenty, to by pak nikdo nemohl používat třeba v kernelu. I když s tou MIT licencí by to byla s kernelem stejně legrace.

[Pali]

LZHAM = Lempel, Ziv, Huffman, Arithmetic, Markov

Ak to Arithmetic znaci aritmeticke kodovanie, tak obavam sa, ze IBM sa len tak lahko patentov nevzda... Prave kvoli tomu sa pouziva BZIP2 a nie BZIP...

[Kvakor]

Patenty IBM už naštěstí vypršely, viz Arithmetic coding/US patents. Ale pravda je, že u Bzip2 byla podpora aritmetického kódování zahozena právě kvůli těmto patentům.

[Bedňa]

Našťastie MS nepodporuje by default žiadne otvorené formáty a nedá sa to rozbaliť. Zdravím užívateľov tohoto úžasného systému.

[teni]

Když voni to mají kuci vod MS těžké: Kdysi dávno chtěli "by default" podporovat otevřený formát HTML. Nabastlili pro to Internet Explorer a pak je norští komunisti od Opery honili po evropských komisích tak dlouho, až z nich vydojili ballot screen. Po takové zkušenosti bych na jejich místě "by default" raději nepodporoval ani ascii.

[Šangala]

Vida další důvod proč Norsku vyhlásit válku, už má důvod i USA (po Rusku a ČR).

[R]

Z tej ich podpory HTML sa dodnes web nespamatal, weby sa robia nie podla standardov ale pre urcite verzie urcitych browserov...

[Václav "Darm" Novák]

Ta zkušenost přišla mnohem později. V tu dobu už mohl WMP dávno podporovat otevřené kodeky, systém umět rozbalovat bzip a jiné otevřené archivy…