Kom igång 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.

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:

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<Paket>.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: <Paket>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 <Paket>_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:

# 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:

{
  "dependencies": [ "boost-program-options", "boost-circular-buffer" ]
}

och pekar ut vcpkg:s toolchain-fil när du konfigurerar:

cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake

Med Conan är det en conanfile.txt:

[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:

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:

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:

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:

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

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

find_package(fmt REQUIRED)

add_executable(app ...)
target_link_libraries(app PRIVATE fmt::fmt)

Vilket sätt ska man välja?

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, 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.

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.

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, tillsammans med en CMakeLists.txt som bygger båda programmen:

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:

// Header-only Boost: a sliding window over the input, via Boost.Circular_buffer.
#include <boost/circular_buffer.hpp>
#include <iostream>
#include <numeric>
#include <string>

auto average(boost::circular_buffer<double> 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<double>(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.

$ 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.

// Compiled Boost library: command-line parsing via Boost.Program_options.
#include <boost/program_options.hpp>
#include <algorithm>
#include <cctype>
#include <iostream>
#include <string>

namespace po = boost::program_options;

int main(int argc, char* argv[]) {
    auto options = po::options_description("Usage: banner [options] <message>");
    options.add_options()
        ("help,h",                                       "show this help")
        ("count,n", po::value<int>()->default_value(1),  "number of repetitions")
        ("upper,u",                                      "print in upper case")
        ("message", po::value<std::string>()->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<std::string>();
    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<int>(); ++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.

$ ./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:

$ 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.