Názory k článku Svět jednohlavičkových knihoven pro jazyky C a C++
-
Jen upozorňuji, že článek je primárně o C. Doufám, že v dalších dílech uvidíme i C++ :-)
Jako výhodou je, že C hlavička jde vložit i do C++. Nevýhodou je, že na styčných místech člověk musí degradovat svůj C++ mind set na prosté C , což nemám rád :-) - takže to pak stejně končí nějakým C++ wrapperem.
-
Pavel TišnovskýZlatý podporovatelChystám se, pomalu, ale chystám. S těmi C++ řešeními je problém ten, že jsou na různé úrovni abstrakce (resp. možná jinak - některé používají starší přístupy, jiné zase to nejnovější, co v C++ je, a ve výsledku se to potom musí ohýbat).
Ale zrovna třeba ty stb knihovny, tam je toho málo céčkového - prostě zavolání jedné funkce, která nemá vnitřní stav a jen něco udělá. Na druhou stranu zase vec.h nebo hashmap.h by asi nikdo v C++ nepoužil :-)
-
Já bych rozlišoval header-only a jednohlavičkové knihovny jako dvě kategorie. Header-only může obsahovat klidně více hlavičkových souborů. V C++ je to často kvůli šablonám, nebo pár řádků inline kódu, ale nemá smysl tam cpát vše. Jednohlavičkové knihovny spojí všechny hlavičkové soubory do jednoho. Mohou, ale nemusí, být header-only. Jednohlavičkové knihovny mi přijdou obecně jako zlo. Je to nepřehledné. Pokud už se autor rozhodne pro jednohlavičkovou knihovnu, tak očekávám perfektní vygenerovanou dokumentaci např. v doxygen. Jako příklad takovéto jednohlavičkové knihovny uvedu například perfetto SDK(https://github.com/google/perfetto). Pokud se chcete podívat, tak SDK u perfetto není přímo v githubu, ale generuje se. Je k dispozici v release zdrojácích(https://github.com/google/perfetto/releases). Hlavičkový soubor sdk/perfetto.h má 7.5MB!
-
Pavel TišnovskýZlatý podporovatel
To je pravda, díky za doplnění.
A ano, může to být zlo, hodně záleží na autorovi. Obecně ty stb knihovny (použil jsem dvě) jsou ok, ale měl jsem v plánu popsat i některé, které jsem nakonec vynechal, protože nejsou až tak pěkné na použití.
-
panikaStříbrný podporovatelSean Barret rikal ze to bylo jedno ze zadani co si dal. Licence aby se daly pouzit kdekoliv a ze nemusi byt nejlepsi a nejrychlejsi ale maji se dat snadno pouzit. Muzu jen doporucit 5hod rozhovor s nim na Wookash podcast.
-
Čiste pre zaujímavosť:
- existuje optimalizačná technika, počas ktorej sa všetky súbory automatizovane pospájajú do jedného a vtedy to vraj prekladač lepšie spracuje. Nikdy som to nepoužil, ale pred viacerými rokmi bola na tú tému aj prednáška na niektorej z hlavných konferencií.
- kdesi som zachytil tiež názor, že každý komponent nemusí mať svoj vlastný hlavičkový alebo implementačný súbor a že veľké súbory nevadia, keď sú dobre štrukturované. Dokonca to bol možno sám Bjarne Stroustrup.
- niekde som čítal o programátorovi, ktorý píše v C a má všetko v jednom súbore, stovky tisíc riadkov. To bol tuším tiež niekto z okruhu okolo Stroustrupa, v každom prípade uznávaný profesionál s výsledkami.
-
SQLite to dělá - říkají tomu amalgamation (https://sqlite.org/amalgamation.html). Je to takové manuální LTO :) Jinak lze to udělat i u normálního projektu a říká se tomu unity build (https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html).
-
Pavel TišnovskýZlatý podporovatel
SQLite to dělá nějakým postprocessingem ne? Tedy zdrojáky mají normálně rozdělené jako projekt, ale při release udělají ten obrovskej céčkovej zdroják. Mám ho shodou okolností na disku a má to 9 MEGAbajtů, 26000 řádků. Kupodivu překlad (bez optimalizací) není tak hroznej:
$ time gcc -c sqlite3.c real 0m4.905s user 0m4.644s sys 0m0.224s
-
Možná se tomu říká unity build, protože tak kompiluje herní engine Unity. EDIT: Aha, v odkazované stránce to je přímo napsané v úvodu ("This is known as a Unity or Jumbo build.").
11. 2. 2026, 16:23 editováno autorem komentáře
-
Říká se tomu Jumbo build nebo Unity build (neplést s herním enginem). Můžeš to udělat třeba tak, že si vytvoříš jeden nový *.c soubor, který bude obsahovat pouze include na všechny ostatní tvoje *.c soubory, nic víc. Pak už budeš kompilovat pouze tento jeden soubor. Nepotřebuješ žádný build systém, make, CMake. Hodně se mi to líbí.
Já bych i psal všechno do jednoho souboru. Když máš dobrý text editor, je to pohoda. ALE já jsem šel už za hranu. Vytvořil jsem si šablony v C. Třeba něco jako std::vector<T> ale v Céčku. Používám to tak, že definuji macro, které říká co se má dosadit za T. Pak includuji můj vector.h. Znovu definuji co se má dosadit za T, tentokrát jiný datový typ a znova includuji můj vector. Tady už musím roztrhat svůj projekt do více souborů.
-
> neplést s herním enginem
Právě že ten je znám tím, že byl jeden z prvních, co tuto techniku kompilace používal.
-
Zrovna ty STB knihovny jsou plné CVE a autor s tím nechce nic dělat. Jsou nebezpečné a dostalo se to i do knihoven jako SDL.
Mi to přijde ujeté. Nechci se naučit tooling, tak vytvořím jeden soubor co má tisíce řádků, nikdo se v tom nevyzná a je tam chyb jako máku. Pořádně testovat radši ne, protože by to znamenalo vytvořit další soubor... No a sám autor na to odpoví, že STB image je jen pro obrázky, které máš pod kontrolou a nejsou malformed...
-
> No a sám autor na to odpoví, že STB image je jen pro obrázky, které máš pod kontrolou a nejsou malformed...
To je pravda. Ale co je na tom špatného?
> Nechci se naučit tooling
Osobně mi nástroje pro buildění C/C++ typu cmake nebo configure + make přijdou strašlivé. Raději si píšu dva skripty, bat soubor pro build na Windows a sh soubor pro build na Macu či Linuxu. Aspoň na první pohled z toho skriptu vidím, jaké flagy jsem předal kompilátoru.
-
panikaStříbrný podporovatel
jeste o kus dal jde nob.h ktery ke kompilovani Ccka pouziva Ccko :)
a hadejco single header :))
https://github.com/tsoding/nob.h -
Špatné je na tom to, že ty STB knihovny používají jiné projekty, jejichž autoři to třeba ani netuší, popřípadě to jsou závislosti dalších projektů, takže konečný uživatel je vystavený nebezpečí a vůbec o tom neví.
Nechápu, že o tom vůbec musí být diskuze - out of bounds access je špatně a když to autor neřeší, tak to hodně vypovídá o tom projektu.
Build system je téma na jinou diskuzi. Vím ale, že bez third party knihoven dnes nic udělat nejde, a cmake (ačkoliv ten scripting language je hrůzný) je zatím to nejvíc funkční řešení, které jsem používal.
-
> Nechápu, že o tom vůbec musí být diskuze - out of bounds access je špatně a když to autor neřeší, tak to hodně vypovídá o tom projektu.
Já myslím, že diskuze efektivně skončila. Autor jednoznačně specifikoval preconditiony. Komu se to nelíbí, musí ty obrázky zkontrolovat sám, nebo použít jinou knihovnu. A ke konečnému uživateli se to může dostat jen přes nepřerušený řetěz knihoven, jejichž autoři řeší bezpečnost +- stejně.
Nemusí se nám to líbit, ale takhle se v C řeší složité problémy odnepaměti. Nedefinované chování, IFNDR, démoni z nosa a tak dále.
-
A k těm build systémům...
IMO nejspolehlivější cesta, jak dotlačit lidi k nebezpečnému chování, je naházet na bezpečnou cestu dost klacků pod nohy. Lidi chcou udělat svou práci s minimem dodatečného opruzu. Cokoliv jim zavazí, budou mít tendenci obcházet.
To, že nejvíc funkční řešení je příšerný cmake je pak důvod, proč jsou tyhle knihovny tak atraktivní. Máte nějakou srovnatelně jednoduchou knihovnu, co na bezpečnost nedlabe? Sem s ní!
-
Pavel TišnovskýZlatý podporovatel
jako že když řeknu, že obrázek má 100x100 pixelů, ale to pole bude menší, tak to udělá nějakou neplechu v paměti? (předpokládám, že jen čte). Jako teoreticky někde při aplikaci RLE nebo LZ77 může dojít k přetečení, ale to možná nemáš na mysli?
10. 2. 2026, 21:54 editováno autorem komentáře
-
To je všechno dohromady. Autor vůbec neřeší out of bounds access atd... Já ani nevím kolik těch chyb tam je, protože sám autor to odmítl řešit s tím, že to bylo navržené jen pro obrázky, které jsou v pořádku. Teoreticky cokoliv typu DEFLATE, RLE, atd... může způsobit out of bounds memory access v této knihovně.
Ještě horší je ale stb_truetype - tam se přičítají offsety z dat TTF bez jakékoliv kontroly, takže to je hodně divoké, a je to "by design".
Toto prostě není dobrý software engineering. Ty knihovny jsou špatně navržené...
-
Pavel TišnovskýZlatý podporovatel
já to chápu pro LOADing, ale pro ukládání moc ne - tam jsou všechny obrázky v pořádku by design ne?
-
ani ja sa nechcem učiť tooling, je ich priveľa a všetko sú to komplikované molochy, čas sa dá využiť aj lepšie. Mám rád c++ z nostalgických dôvodov, ale väčšinou robím C#, C++ len na starých projektoch a problémy s tým, ako skompilovať projekt s rôznymi knižnicami rôznych autorov je jeden z dôvodov, prečo by som v c++ nový projekt nezačínal
ČLÁNKY DO MAILU