# Brigand: a compile-time C++11 library that took over from Boost.MPL > Brigand is a light-weight, fully functional, instant-compile time C++11 meta-programming library that set out to do everything Boost.MPL did, and it was built as a usable alternative rather than as an experiment. It suits a team maintaining a C++11 codebase that has outgrown hand-written template code, and the thing to weigh first is that the last tagged release is from 2016 even though the repository is still being pushed to. **edouarda/brigand** — Instant compile time C++ 11 metaprogramming library - Repository: https://github.com/edouarda/brigand - Stars: 570 · Forks: 48 - Language: C++ - License: BSL-1.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/edouarda-brigand ## The claim is a replacement, not a supplement Brigand is described in one line that tells you the whole project: a light-weight, fully functional, instant-compile time C++ 11 meta-programming library. The positioning statement that follows is unusually direct. Everything you were doing with Boost.MPL can be done with Brigand, and if that is not the case, open an issue. There is no hedging and no framing as an experiment. A library that replaces an established one has to make a completeness claim, and this one makes it explicitly, which tells you that the author intended it as a drop-in rather than as a complement. That matters for the reader because Boost.MPL is a heavy dependency to carry for what it does. A metaprogramming library is compile-time infrastructure: it is pulled in by the headers that use it, it participates in the template instantiation cost of everything it touches, and Boost is a large body of code to take on for that. A library whose stated advantage is instant compile time is aimed squarely at that cost. The three adjectives in the description each carry a design constraint. Light-weight is about what you inherit. Fully functional is about the completeness claim above. Instant-compile time is about the template instantiation strategy, which is the actual subject of the library rather than a marketing line. The C++11 part is equally load-bearing. The library targets the standard that introduced variadic templates and type lists via parameter packs, which is what makes a modern alternative to MPL possible at all. An MPL-style library is a hierarchy of nested type containers, and C++11 gives a much flatter and more direct way to express the same thing. The project was written when that was new, and the design follows from it. ## A repository that packages itself rather than relying on Boost The repository layout tells you how a library like this is meant to be consumed, and it is not the usual header-only dump. At the top there is an `include/` directory, which is where the public headers live for a consumer adding it to a project. The `libbrigand.pc.in` file is a pkg-config template, which is the giveaway that this library is meant to be found and linked by a build system rather than pasted into a project. There is a `CMakeLists.txt` and a `CMake/` directory, and a `debian/` directory, so the library has packaging for a Linux distribution as well as the usual source inclusion. A `doc/` directory holds documentation, `examples/` holds the example programs, `test/` the test suite, `script/` the helper scripts, and `meta/` sits alongside them as a directory with its own purpose that the README does not spell out, most likely holding the list-style machinery the library operates on. The `examples/` directory is split into `algorithms/` and `sequences/`, which is a useful piece of taxonomy. Algorithms are the things you compute over a list, and sequences are the lists themselves, and a metaprogramming library that separates those two concerns is making a statement about how you write the code that uses it. The `examples/CMakeLists.txt` at the top of that directory means the examples are built as part of the project's own build rather than being documentation snippets you copy. That is the difference between a wiki page and a compiled example, and for a compile-time library it is the only kind of example that proves anything. The build badges point at Travis CI and AppVeyor, which is the pair that was standard for a project of this vintage, and the `.clang-format` file at the root means the code is formatted with clang-format and the style is checked. ## Learning resources, because a compile-time library is hard to learn from an API list The Learning section is not an afterthought here, and that is a deliberate choice rather than a gap in documentation. The first pointer is a Meeting C++ 2015 lightning talk, offered as a way to learn more if you wish to. The second is the CppCon 2016 presentation, which the README says explains the library concepts in detail and goes through two concrete usages. The third is a free O'Reilly e-book on practical C++ metaprogramming, suggested for anyone looking to learn the concepts rather than the API. The order is deliberate, and it runs from shortest to longest. A lightning talk is a few minutes of orientation, a conference presentation is the detailed treatment with worked examples, and the e-book is the background for the ideas themselves. That is a sensible curriculum for a subject where the concepts are the hard part and the API reference only tells you what exists. The tutorials in the wiki follow the same split into three named topics: an Introduction, Algorithms and Runtime. Introduction is presumably the concepts, Algorithms is presumably the catalogue of what you can compute over a type list, and Runtime is presumably the part that talks to the underlying runtime facilities. Knowing that the algorithms are a separate tutorial page is useful, because in a metaprogramming library the list of available operations is the part you will look up repeatedly, and it is a wiki page rather than something you find by reading headers. The documentation itself is the wiki, linked as available here, with the tutorials being its three entry points. For a project from this period, a wiki rather than a generated site was normal, and the practical consequence for a reader today is that the content is whatever was last edited rather than something kept in step with the code by the build. ## Three releases with names, and no tag in a decade The release history is short and unusually well named. Version 1.3.0 is Brigand 1.3.0 - The Last Outpost, from 2016-11-13. Version 1.2.0 is Brigand 1.2.0 - Code of Honor, from 2016-05-08. Version 1.1.0 is Brigand 1.1.0 - The Naked Now, from 2016-01-12. The names are a nice touch for a library with a military theme, and they are the only record of what changed in each release, because the README carries no changelog section and the release titles say nothing about functionality. If you are trying to work out what a version bump changes for your code, the wiki and the commits are where you have to look. Three minor releases over a year, all in 2016, is the shape of a library that reached a stable point and then stopped being versioned. The last push was on 2026-08-07, so the repository is being touched, but no release has been tagged since November 2016. That combination, repository alive and tags frozen, is the thing to weigh before adopting. It can mean several things. It can mean the library is stable enough that nothing needs releasing, which is the friendliest reading, and a header-only metaprogramming library that compiles is not obviously going to need a new release for a bug fix in the library itself. It can also mean the ecosystem moved on and the maintenance is limited to keeping the build working on new compilers. The Licence situation suggests the second reading is worth taking seriously, since a permissive licence that is not a standard one is a sign of a project that stopped chasing a broad audience. The licence is BSL-1.0, the Boost Software Licence 1.0, which is a permissive, source-available licence. The project is not archived, and the last push is recent, so the code is not frozen even if the tags are. ## Whether Brigand is still the right answer depends on your standard The comparison worth making is with the two alternatives that a C++ team has for compile-time computation, because Brigand was written to displace one of them and the other has since improved. The first alternative is Boost.MPL itself, and that is the comparison the project makes. For a codebase that has been on Boost.MPL for a decade and works, the migration cost is real, and Brigand's advantage of a smaller, faster dependency only pays off if you are also fixing the compile-time problem that brought you to the library in the first place. The second alternative is what the standard library itself now offers. C++17 brought fold expressions, and C++20 brought concepts and consteval, and a lot of what a metaprogramming library was needed for can now be written directly or with a constraint. A team on a recent standard may find that a small hand-written trait set replaces a library dependency entirely, which is the outcome Brigand was designed to make possible for C++11 users and that later standards partly made unnecessary. The honest practical test is about compile time, because that is the problem the library names. If your build spends minutes in template instantiation, Brigand is a targeted tool for that, and the fact that it was written for C++11 rather than for the latest standard is less of a problem than it sounds, since a metaprogramming library operates on types rather than on library features, and C++11 is a wide compatibility floor rather than a narrow one. What to check before committing is the algorithm catalogue. The wiki has an Algorithms page, and if the operations your code needs are there, the library covers you. If they are not, you are looking at writing them, and at that point the library's value depends on how good its extension points are, which is a question the README does not answer. For an existing C++11 project, the case is clear. For a new one on a modern standard, it is worth an afternoon of comparison before you take on a dependency that has not been released in a decade. ## Conclusion Adopt Brigand if you are on C++11 and want a metaprogramming library that compiles fast without dragging in Boost, since that is exactly the claim the project makes and the reason the design exists. Do not adopt it for a new C++17 or C++20 codebase without checking the ecosystem first, because the last tagged release is 1.3.0 from 2016 and the newer standard libraries have their own approaches, and check first that the algorithms you need exist in the wiki tutorials before committing, because the documentation is organised around three topics rather than a complete reference. ## FAQ ### What is Brigand? It is a light-weight, fully functional, instant-compile time C++ 11 meta-programming library, created as an alternative to Boost.MPL with the claim that everything you were doing with Boost.MPL can be done with Brigand. The project is licensed under the Boost Software Licence 1.0. ### How do I install Brigand in a C++ project? The repository ships a pkg-config template in libbrigand.pc.in, a CMakeLists.txt with a CMake directory, and a debian directory for distribution packaging, alongside the include directory with the public headers. The examples directory has its own CMakeLists.txt, so the example programs are built as part of the project rather than being documentation snippets. ### Where can I learn how Brigand works? The README points to a Meeting C++ 2015 lightning talk for a quick orientation, a CppCon 2016 presentation that explains the library concepts in detail with two concrete usages, and a free O'Reilly e-book on practical C++ metaprogramming for the background. The wiki itself has three tutorials: Introduction, Algorithms and Runtime. ### Is Brigand still being maintained? The repository is not archived and the last push was on 2026-08-07, but the tagged releases stopped in 2016 with 1.3.0, after 1.2.0 and 1.1.0 earlier that year. The README carries no changelog, so the wiki and the commits are where you have to look for what changed. ### How does Brigand compare with Boost.MPL? Brigand was written to be a replacement rather than a supplement, and the README states that everything you were doing with Boost.MPL can be done with Brigand. Its stated advantage is instant compile time and a smaller dependency, at the cost of a migration since the APIs and the type list machinery differ. ### What is the Brigand licence? BSL-1.0, the Boost Software Licence 1.0, which is a permissive source-available licence. The repository has both a LICENSE file and a debian directory, and the build is checked on Travis CI and AppVeyor with a .clang-format at the root. ## Sources - [edouarda/brigand on GitHub](https://github.com/edouarda/brigand) - [Issues](https://github.com/edouarda/brigand/issues) - [License: BSL-1.0](https://github.com/edouarda/brigand/blob/master/LICENSE) - [README](https://github.com/edouarda/brigand/blob/master/README.md) - [Releases](https://github.com/edouarda/brigand/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/edouarda-brigand