# Kom igång med Boost 2 oktober 2026 | https://www.ribomation.se/blog/2026/kom-igang-med-boost/ Förr eller senare behöver varje C++-programmerare något som standardbiblioteket inte har. En ringbuffert, en parser för kommandoradsargument, en konfigurationsfil, heltal med fler siffror än vad som får plats i 64 bitar. Då står man inför valet att skriva det själv, eller att leta upp ett tredjepartsbibliotek — och i de allra flesta fall slutar det letandet i **Boost**. Det är samlingen som gav oss `shared_ptr`, `optional` och `filesystem` långt innan de fanns i std, och som fortfarande har betydligt mer att erbjuda än det som hittills flyttat in i standarden. Boost har dock ett rykte om sig att vara besvärligt att komma igång med. Det finns flera olika sätt att installera det, en del bibliotek är bara header-filer medan andra ska kompileras och länkas, och mycket av det man hittar på nätet beskriver hur det gick till för tio år sedan. I den här artikeln reder jag ut det: vad Boost är och varifrån det kommer, fyra sätt att få det installerat, vad `CONFIG` i `find_package()` betyder, hur man hittar rätt bland runt 170 bibliotek, och varför jag rekommenderar statisk länkning. Till sist bygger vi två kompletta program — ett med ett header-only-bibliotek och ett som länkas statiskt. All kod är byggd och körd på riktigt, och finns på GitHub. * * * Vad är Boost? ------------- Standardbiblioteket i C++ är medvetet litet. Det som hamnar där ska fungera på allt från mikrokontroller till stordatorer, och det ska vara spikat för all framtid — vilket gör att det tar lång tid innan något kommer in, och att mycket aldrig gör det. Behöver du en ringbuffert, en kommandoradsparser, heltal med tusentals siffror eller en konfigurationsfil i INI-format, så får du antingen skriva det själv eller leta upp ett tredjepartsbibliotek. Det är där Boost kommer in. Boost är en samling av runt 170 C++-bibliotek, som täcker allt från strängbearbetning och containrar till matematik, parsning, concurrency, nätverk och mycket mer därtill. Tre saker skiljer Boost från en godtycklig samling bibliotek på GitHub: * **Peer review.** Ett bibliotek kommer inte in i Boost för att någon tycker det är en bra idé. Det granskas offentligt av andra utvecklare — design, implementation, dokumentation och tester — och blir ofta underkänt första gången. * **Licensen.** Allt ligger under _Boost Software License_, som är en av de mest tillåtande licenser som finns. Du får använda Boost i kommersiell kod, länka statiskt och skeppa binären utan att behöva redovisa något för dina kunder. * **Portabiliteten.** Boost byggs och testas med GCC, Clang och MSVC, på Linux, macOS och Windows. ### Historien Idén föddes på standardkommitténs möte i Sophia Antipolis i Frankrike, i mars 1998. Två av kommitténs medlemmar, **Beman Dawes** och **Robert Klarer**, diskuterade hur man skulle kunna få fram bra kandidater till standardbiblioteket, och strax därefter anslöt **Dave Abrahams** och startade den första e-postlistan. Namnet säger det mesta: målet var att ge C++ och dess biblioteksekosystem en _boost_. Den första utgåvan kom 1999. Från början var Boost uttryckligen tänkt som en plantskola för standarden: skriv biblioteket, låt folk använda det på riktigt i några år, och föreslå det sedan till kommittén när designen har satt sig. Det har fungerat bättre än någon nog vågade hoppas. Från Boost Till std `shared_ptr`, `weak_ptr`, `function`, `bind`, `regex`, `thread`, `chrono`, `random`, `tuple`, `array`, `unordered_map`, `error_code` C++11 `filesystem`, `optional`, `variant`, `any`, `string_view` C++17 `stacktrace` C++23 Filesystem är ett bra exempel. Det skrevs av Beman Dawes själv, användes i Boost i över tio år och blev sedan grunden för `std::filesystem` i C++17. Beman Dawes gick bort 2020, och idag förvaltas Boost organisatoriskt av _The C++ Alliance_. Det kommer tre utgåvor per år — i april, augusti och december — och i den här artikeln använder jag den senaste, **Boost 1.92.0** från augusti 2026. > Om std redan har `filesystem`, `optional` och `regex`, varför ska man då bry sig om Boost idag? Därför att det som har flyttat in i std är en bråkdel av det som finns. Ringbuffertar, bimaps, containrar med flera index, godtyckligt stora heltal, parsergeneratorer, tillståndsmaskiner, grafalgoritmer, kommandoradsparsning — inget av det finns i std, och det mesta kommer aldrig att göra det heller. ### Hur vanligt är Boost? Jag har inte hittat någon pålitlig siffra, men min erfarenhet från kurser och konsultuppdrag är entydig: i princip varje större C++-kodbas jag har sett har lite Boost någonstans. Ibland är det bara ett par header-filer, ibland är hela arkitekturen byggd kring Boost.Asio. Boost finns dessutom paketerat i varenda Linux-distribution och i alla stora pakethanterare för C++, vilket i sig säger en del. * * * Installation ------------ Det finns minst fyra sätt att få Boost på plats, och de har olika styrkor. Gemensamt för alla är att det slutar på samma sätt i din `CMakeLists.txt`: ```cmake find_package(Boost 1.92 CONFIG REQUIRED COMPONENTS program_options) target_link_libraries(app PRIVATE Boost::program_options) ``` Lägg märke till `CONFIG`. Det hänger ihop med att `find_package()` kan arbeta på två sätt. **Module mode** är det gamla sättet. CMake letar efter en fil `Find.cmake`, först i `CMAKE_MODULE_PATH` och sedan bland CMakes egna moduler. En sådan fil är ett skript som någon _annan_ än paketets författare har skrivit, och det gissar: det letar efter header-filer och biblioteksfiler på vanliga ställen, och försöker räkna ut version, beroenden och kompileringsflaggor. Det fungerar så länge gissningen stämmer. Problemet är att modulen måste uppdateras varje gång paketet ändrar sig. Den `FindBoost.cmake` som följde med CMake under många år hade till exempel en hårdkodad lista över Boost-versioner och bibliotekens inbördes beroenden — och låg alltid efter. **Config mode** innebär att CMake i stället letar efter en fil som _paketet självt_ installerade: `Config.cmake`. För Boost ligger den i `lib/cmake/Boost-1.92.0/BoostConfig.cmake`, med en egen katalog per bibliotek bredvid, som `lib/cmake/boost_program_options-1.92.0/`. Filerna genererades när Boost byggdes, och beskriver därför exakt det som installerades: sökvägar, statisk eller dynamisk länkning, kompileringsdefinitioner och beroenden till andra Boost-bibliotek. Inget behöver gissas. De definierar importerade mål som `Boost::program_options`, med all den informationen inbakad, och det är därför `target_link_libraries()` ovan räcker. Var CMake letar styrs av `_ROOT`, `CMAKE_PREFIX_PATH` och systemets standardplatser, som `/usr/lib/cmake`. Utan nyckelordet provar `find_package()` först module mode, och faller tillbaka på config mode om ingen `Find`\-modul hittas. Med `CONFIG` hoppar man över module mode helt. Kort sagt: i module mode är det någon annan som beskriver paketet, i config mode beskriver paketet sig självt. Det senare är det moderna sättet, och det är därför CMake kunde ta bort sin `FindBoost`\-modul i version 3.30 (policy CMP0167). Ser du `Boost_USE_STATIC_LIBS` eller `${Boost_LIBRARIES}` i en gammal byggfil, så är det den gamla modulen som spökar. ### Via operativsystemets pakethanterare Det enklaste sättet, och det som de flesta börjar med: ```bash # Debian, Ubuntu $ sudo apt install libboost-all-dev # Fedora, RHEL $ sudo dnf install boost-devel # macOS $ brew install boost # Arch $ sudo pacman -S boost ``` Nackdelen är att versionen ligger efter. Ubuntu 26.04 LTS, som jag kör, levererar Boost 1.90 — två utgåvor bakom. Och med en LTS-utgåva står man kvar på den versionen i flera år. Paketet `libboost-all-dev` drar dessutom in allt, inklusive bibliotek för Python och MPI som du förmodligen aldrig kommer att använda. Vill du vara mer selektiv finns det enskilda paket, som `libboost-program-options-dev`. ### Via vcpkg eller Conan De två stora fristående pakethanterarna för C++ har båda Boost, uppdelat per bibliotek. I vcpkg beskriver du beroendena i en manifestfil `vcpkg.json`, som ligger bredvid `CMakeLists.txt`: ```json { "dependencies": [ "boost-program-options", "boost-circular-buffer" ] } ``` och pekar ut vcpkg:s toolchain-fil när du konfigurerar: ```shell cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake ``` Med Conan är det en `conanfile.txt`: ```ini [requires] boost/1.91.0 [generators] CMakeDeps CMakeToolchain ``` följt av `conan install . --build=missing` och en CMake-körning med den toolchain-fil som Conan genererar. Båda bygger från källkod första gången, och båda cachar resultatet. I skrivande stund har vcpkg redan 1.92.0, medan Conan Center ligger på 1.91.0. > En sidnot för Windows-folket: vcpkg är det naturliga valet där, eftersom det är välintegrerat med Visual Studio. Värt att känna till är också att Boost på MSVC har _autolinking_ — header-filerna innehåller `#pragma comment(lib, ...)`, så att länkaren själv hittar rätt `.lib`\-fil. Det är bekvämt tills det inte fungerar; då kan du stänga av det med `BOOST_ALL_NO_LIB` och låta CMake sköta länkningen som på alla andra plattformar. ### Via CMake FetchContent Sedan några år har Boost fullt stöd för att byggas med CMake, och för varje utgåva finns ett färdigt källkodsarkiv avsett just för det. Det betyder att du kan låta CMake ladda ned och bygga Boost som en del av ditt eget projekt: ```cmake include(FetchContent) set(BOOST_INCLUDE_LIBRARIES program_options) # configure & build only what we need set(BUILD_SHARED_LIBS OFF) # link Boost statically FetchContent_Declare(Boost URL https://github.com/boostorg/boost/releases/download/boost-1.92.0/boost-1.92.0-cmake.tar.xz URL_HASH SHA256=9bed76128d4e46755dbe818487788c6fceb6f72b378f4daa49b7e1e600d9088d DOWNLOAD_EXTRACT_TIMESTAMP ON EXCLUDE_FROM_ALL) FetchContent_MakeAvailable(Boost) add_executable(banner src/banner.cxx) target_link_libraries(banner PRIVATE Boost::program_options) ``` Det viktiga här är `BOOST_INCLUDE_LIBRARIES`. Utan den konfigureras alla Boost-bibliotek, vilket tar tid. Med den tas bara de bibliotek med som du räknar upp, plus det de i sin tur är beroende av. Hela övningen — nedladdning av drygt 100 MB, konfigurering och bygge — tog knappt en halv minut hos mig. _Fördelen_ är att projektet blir självförsörjande: den som klonar ditt repo behöver inte installera något först. _Nackdelen_ är att det första bygget tar tid, och att varje projekt får sin egen kopia av Boost. Om du räknar med att använda Boost i flera olika projekt, så slösar du diskutrymme helt i onödan. Lite grann som Node.js/NPM-projekt. ### Ladda ned och bygg själv Det sista alternativet är det jag själv använder. Jag har en katalog `~/Libs`, där jag bygger de C++-bibliotek jag använder ofta. Där ligger varje version i en egen katalog, med en symbolisk länk `latest` som pekar på den senaste: ```text Libs/ ├── Archives/ # nedladdade källkodsarkiv ├── CMake-modules/ # egna Find.cmake ├── Boost/ │ ├── boost-1.91.0/ │ ├── boost-1.92.0/ # include/, lib/, lib/cmake/ │ └── latest -> boost-1.92.0 └── ... ``` Själva bygget görs med samma CMake-arkiv som ovan. Jag bygger alltid statiskt och i release-läge: ```shell tar xf Archives/boost-1.92.0-cmake.tar.gz cmake -S boost-1.92.0 -B boost-build -G Ninja \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_CXX_STANDARD=20 \ -DBUILD_SHARED_LIBS=OFF \ -DCMAKE_INSTALL_PREFIX=$HOME/Libs/Boost/boost-1.92.0 cmake --build boost-build cmake --install boost-build ln -sfn boost-1.92.0 $HOME/Libs/Boost/latest ``` Därefter räcker det att tala om för CMake var Boost finns: ```shell cmake -S . -B build -DBoost_ROOT=$HOME/Libs/Boost/latest ``` I mitt fall har jag dessutom en liten egen `FindBoost.cmake` i `Libs/CMake-modules/` som räknar ut sökvägen själv och sedan lämnar över till Boosts egna konfigurationsfiler. Det gör att applikationerna behöver bara lägga till katalogen i `CMAKE_MODULE_PATH`. Varför så omständligt? Därför att jag vill ha den senaste versionen, oberoende av vad Ubuntu råkar leverera, och samma version i alla mina projekt. Uppgraderingen till en ny Boost-version är en nedladdning, ett bygge och en ny symbolisk länk — ingen applikation behöver ändras. > Det klassiska sättet att bygga Boost är inte med CMake, utan med Boosts eget byggsystem **b2** (en gång i tiden kallat _bjam_). Det finns fortfarande kvar, och det är det många äldre instruktioner på nätet beskriver: `./bootstrap.sh` följt av `./b2 install --prefix=... link=static variant=release cxxstd=20`. Resultatet är detsamma, men om du redan bygger allt annat med CMake finns det ingen anledning att lära sig ett byggsystem till. **För transparensens skull, bör jag nämna att**: jag ber _Claude Code_ utföra allt arbete i stället för att göra det själv. Jag har en agent skill som beskriver målsättning, kataloglayout och tillvägagångssätt. Sen kan jag enkelt be Claude installera, t.ex. `{fmt}` via `/install-cpp-lib fmt` och strax finns detta på plats och kan användas i ett CMake-projekt via en specialskriven _CMake-modul_. Denna modul (och övriga) blir tillgängliga för CMake via ```cmake list(APPEND CMAKE_MODULE_PATH "/your/path/to/Libs/CMake-modules") ``` Sedan kan man infoga önskade bibliotek, t.ex. för `{fmt}`, på följande sätt ```cmake find_package(fmt REQUIRED) add_executable(app ...) target_link_libraries(app PRIVATE fmt::fmt) ``` ### Vilket sätt ska man välja? Sätt Version Första bygget Bäst när apt, dnf, brew ofta flera bakom ingen du vill komma igång på fem minuter vcpkg, Conan nära den senaste lång flera plattformar, Windows FetchContent exakt den du väljer lång repot ska byggas utan förberedelser bygga själv exakt den du väljer en gång du har flera projekt och vill ha kontroll * * * Efter installationen — hitta rätt --------------------------------- Med runt 170 bibliotek är den första utmaningen att hitta det man behöver. Startpunkten är [boost.org/libraries](https://www.boost.org/libraries/latest/categories/), där biblioteken finns grupperade per kategori, och där varje bibliotek har en länk till sin dokumentation. Vill du läsa dokumentationen för exakt den version du har installerat, så finns den under en versionsspecifik sökväg, som [boost.org/doc/libs/1\_92\_0](https://www.boost.org/doc/libs/1_92_0/). Håll i minnet att Boost är en samling av olika opens source-bibliotek skapade av olika programmerare med olika syn på det här med dokumentation. Somligt är föredömligt med introduktion, handledning och referens. Medan annat har stor förbättringspotential för att formulera sig diplomatiskt, i stället för att kort och gott säga RTFC! Exemplen i bibliotekets katalog `example/` på GitHub är många gånger den bästa ingången. Här är ett urval, kategori för kategori. Långt ifrån komplett, men tillräckligt för att ge en känsla för bredden. Kategori Exempel på bibliotek Strängar och text String\_algo, Lexical\_cast, Format, Locale, Regex, Charconv Containrar Container (`flat_map`, `small_vector`, `static_vector`), Circular\_buffer, Bimap, Multi\_index, Unordered Matematik och numerik Multiprecision, Math, Accumulators, Random, Rational, Safe\_numerics Parsning och dataformat Spirit, Parser, Program\_options, Property\_tree, JSON, URL, Serialization Metaprogrammering och reflektion MP11, Hana, Describe, PFR Samtidighet Thread, Fiber, Lockfree, Cobalt, Asio System och I/O Filesystem, Process, Iostreams, Interprocess, Stacktrace, Log Testning Test Domänspecifikt Graph, Geometry, GIL (bildbehandling), Date\_time, Units Asio kommer att få en egen artikel, så den lämnar jag därhän här. > Boost-biblioteken är inte oberoende av varandra. Tvärtom — de bygger i hög grad på varandra, och ett litet bibliotek som Circular\_buffer drar direkt in sju andra, och ytterligare några indirekt, via sina header-filer. Det är skälet till att man i praktiken alltid installerar hela header-trädet, även om man bara använder en enda komponent. * * * Header-only eller kompilerat ---------------------------- Den viktigaste praktiska distinktionen i Boost är den mellan bibliotek som bara består av header-filer, och bibliotek som har en kompilerad del som ska länkas in. **De flesta biblioteken är header-only.** Du inkluderar en header-fil och kompilerar — klart. Alla template-baserade bibliotek hamnar naturligt här, liksom en hel del annat. I CMake motsvaras det av målet `Boost::headers`, som inte innehåller något annat än sökvägen till header-filerna. **Ett trettiotal bibliotek har en kompilerad del.** Det gäller bibliotek med kod som inte är templates, och som därför inte gärna kompileras om i varje översättningsenhet. Några av dem: Program\_options, Filesystem, Iostreams, Serialization, Thread, Locale, Log, JSON, URL, Process, Charconv, Container och Test. För dem finns det ett CMake-mål per bibliotek, som `Boost::program_options`, och det tar med sig både header-filerna och biblioteksfilen, samt de andra Boost-bibliotek det i sin tur är beroende av. Gränsen flyttar sig över tid, och då i riktning mot header-only. Boost.System var länge ett kompilerat bibliotek, men är header-only sedan 1.69. Boost.Regex blev header-only i 1.76. Kontrollera därför i dokumentationen för just din version, snarare än att lita på gamla instruktioner på nätet. ### Statiskt eller dynamiskt? För de kompilerade biblioteken väljer du när Boost byggs om du vill ha statiska bibliotek (`libboost_program_options.a`) eller dynamiska (`libboost_program_options.so`). I CMake styrs det av `BUILD_SHARED_LIBS`, med b2 av `link=static` eller `link=shared`. Personligen rekommenderar jag **statisk länkning**, av flera skäl: * Du får en fristående exekverbar fil. Den kan kopieras till en annan maskin, eller läggas i en minimal container-image, utan att man behöver tänka på vilken Boost-version som finns installerad där. * Du slipper versionsproblem i drift. Boost lovar inte binärkompatibilitet mellan versioner, så ett program länkat mot `libboost_*.so.1.90.0` vill ha just 1.90 vid körning. Det gör uppgraderingar av operativsystemet till ett lotteri. * Länkaren tar bara med den kod som faktiskt används, och länktidsoptimering (LTO) får mer att arbeta med. * Licensen tillåter det utan förbehåll — till skillnad från t.ex. LGPL-bibliotek. Nackdelarna är att binärerna blir större, och att varje program måste länkas om för att få del av en buggfix i Boost. För de flesta applikationer är det ett billigt pris. > Vill du ändå länka dynamiskt på Windows behöver du definiera `BOOST_ALL_DYN_LINK`, så att autolinkingen väljer importbiblioteken i stället för de statiska. * * * Två kompletta exempel --------------------- All kod nedan finns i [demo-repot](https://github.com/ribomation/boost-getting-started-demo), tillsammans med en `CMakeLists.txt` som bygger båda programmen: ```cmake cmake_minimum_required(VERSION 3.28) project(boost-getting-started LANGUAGES CXX) set(CMAKE_CXX_STANDARD 23) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) add_compile_options(-Wall -Wextra -Wpedantic) find_package(Boost 1.92 CONFIG REQUIRED COMPONENTS program_options) add_executable(moving-average src/moving-average.cxx) target_link_libraries(moving-average PRIVATE Boost::headers) add_executable(banner src/banner.cxx) target_link_libraries(banner PRIVATE Boost::program_options) ``` Lägg märke till att `circular_buffer` inte står bland komponenterna i `find_package()`. Header-only-bibliotek har ingen egen komponent; de följer med `Boost::headers`. ### Header-only: Circular\_buffer En ringbuffert är en kö med fast kapacitet, där det äldsta elementet försvinner när ett nytt läggs till i en full buffert. Den är perfekt för glidande medelvärden, historik och loggning av de senaste _N_ händelserna. Det finns ingen i std — om du läste artikeln om C++26 Contracts kommer du ihåg att jag skrev en egen där — men i Boost finns `boost::circular_buffer`: ```cpp // Header-only Boost: a sliding window over the input, via Boost.Circular_buffer. #include #include #include #include auto average(boost::circular_buffer const& window) -> double { return std::accumulate(window.begin(), window.end(), 0.0) / window.size(); } int main(int argc, char* argv[]) { auto const capacity = argc > 1 ? std::stoul(argv[1]) : 3UL; auto window = boost::circular_buffer(capacity); auto value = 0.0; while (std::cin >> value) { window.push_back(value); // when full, the oldest value is dropped std::cout << "["; for (auto x : window) std::cout << " " << x; std::cout << " ] avg=" << average(window) << "\n"; } } ``` Som synes beter sig `circular_buffer` som vilken std-container som helst: den har `push_back()`, `size()`, iteratorer och fungerar med `std::accumulate()` och range-for. Det enda som skiljer är att kapaciteten anges när bufferten skapas, och att den aldrig växer. ```text $ echo "3 5 7 9 11" | ./build/moving-average 3 [ 3 ] avg=3 [ 3 5 ] avg=4 [ 3 5 7 ] avg=5 [ 5 7 9 ] avg=7 [ 7 9 11 ] avg=9 ``` ### Statiskt länkat: Program\_options Varje kommandoradsverktyg behöver tolka sina argument, och att göra det för hand med `argv` blir snabbt en härva av `if`\-satser. Boost.Program\_options låter dig i stället deklarera vilka flaggor som finns, vilken typ de har och vilka standardvärden de har. Hjälptexten får du på köpet. ```cpp // Compiled Boost library: command-line parsing via Boost.Program_options. #include #include #include #include #include namespace po = boost::program_options; int main(int argc, char* argv[]) { auto options = po::options_description("Usage: banner [options] "); options.add_options() ("help,h", "show this help") ("count,n", po::value()->default_value(1), "number of repetitions") ("upper,u", "print in upper case") ("message", po::value()->required(), "the text to print"); auto positional = po::positional_options_description(); positional.add("message", 1); auto args = po::variables_map(); try { po::store(po::command_line_parser(argc, argv) .options(options).positional(positional).run(), args); if (args.contains("help")) { std::cout << options << "\n"; return 0; } po::notify(args); // throws if a required option is missing } catch (po::error const& err) { std::cerr << "error: " << err.what() << "\n" << options << "\n"; return 1; } auto message = args["message"].as(); if (args.contains("upper")) std::ranges::transform(message, message.begin(), [](unsigned char ch) { return std::toupper(ch); }); for (auto k = 0; k < args["count"].as(); ++k) std::cout << message << "\n"; } ``` Den lite ovanliga syntaxen i `add_options()` — en lång rad parentesuttryck efter varandra — fungerar därför att `add_options()` returnerar ett objekt med en överlagrad `operator()`, som i sin tur returnerar sig självt. Namnet `"count,n"` ger både den långa formen `--count` och den korta `-n`. Det positionella argumentet gör att meddelandet kan skrivas utan `--message` framför. Hjälpkontrollen görs före `po::notify()`, eftersom det är `notify()` som kontrollerar att obligatoriska värden finns. Annars skulle `banner --help` klaga på att meddelandet saknas. ```text $ ./build/banner -n 2 --upper "hello boost" HELLO BOOST HELLO BOOST $ ./build/banner error: the option '--message' is required but missing Usage: banner [options] : -h [ --help ] show this help -n [ --count ] arg (=1) number of repetitions -u [ --upper ] print in upper case --message arg the text to print ``` Att Boost verkligen är statiskt inlänkat ser man med `ldd`, som listar vilka dynamiska bibliotek en exekverbar fil behöver vid körning: ```text $ ldd build/banner linux-vdso.so.1 libstdc++.so.6 => /opt/gcc-16.1/lib64/libstdc++.so.6 libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 libgcc_s.so.1 => /opt/gcc-16.1/lib64/libgcc_s.so.1 libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 ``` Inte ett spår av `libboost_*`. Hela programmet, inklusive Program\_options, är en fil på drygt 500 KB som kan kopieras till vilken Linux-maskin som helst med en tillräckligt ny `libstdc++`. * * * Sammanfattning -------------- Boost är det naturliga nästa steget när standardbiblioteket inte räcker till. Runt 170 peer-granskade bibliotek, under en licens som låter dig göra i princip vad du vill, och med en historik som gjort det till en plantskola för C++-standarden. Att komma igång handlar om tre saker. Först installationen — via operativsystemets pakethanterare om du vill komma igång snabbt, via vcpkg eller Conan om du bygger för flera plattformar, via FetchContent om repot ska vara självförsörjande, eller som jag själv gör: bygg en gång och låt alla projekt dela på resultatet. Därefter `find_package()` i config mode, så att det är Boost självt som berättar för CMake vad som installerats. Och sist skillnaden mellan header-only-bibliotek, som bara kräver `Boost::headers`, och de kompilerade, som du med fördel länkar statiskt. De två exemplen i artikeln var avsiktligt små. I nästa veckas artikel tar vi ett större grepp, och bygger ett program som laddar ned väderdata från NOAA — dagliga mätningar från tusentals väderstationer, ända tillbaka till 1929 — och packar upp, tolkar och aggregerar den i ett enda flöde. Där får flera Boost-bibliotek samverka: Program\_options, Property\_tree, Iostreams, String\_algo och Accumulators, samt en första glimt av Beast.