Vlákno názorů k článku Svět jednohlavičkových knihoven pro jazyky C a C++ od Baloun - Já bych rozlišoval header-only a jednohlavičkové knihovny jako...
-
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ý podporovatelTo 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.