Feature flags in C++: managing features without pain and rebuilding

Why do C++ projects need feature flags? Let's figure it out in practice

Imagine: you are writing a library for image processing. A new version of the compression algorithm gives +30% speed, but requires refinement for specific processor architectures. Releasing it immediately is risky. Not releasing it means losing a competitive advantage. A familiar dilemma?

In the world of web development, this problem has long been solved using feature flags (also known as feature toggles or functionality flags). But in the C++ ecosystem, they are treated with caution: "This isn't PHP, we have native compilation, every if matters here." And that's a mistake. Feature flags in C++ are not about slowing down, but about control. Let's figure out how to implement them without pain, preserving performance and common sense.

What are feature flags and why they are needed specifically in C++

A feature flag is a conditional switch that allows you to enable or disable functionality without changing code and recompiling. In C++, this is especially relevant due to the specifics of the language:

\n
• Long build times — recompiling the entire project for a single flag is expensive.
\n
• Different platforms — one feature may work on Linux and crash on Windows.
\n
• A/B testing — want to test a new parser? Enable it for 5% of users.
\n
• Canary releases — roll out features to a small audience without affecting everyone.
\n

The main fear of C++ developers is that flags will clutter the code and kill performance. But if approached wisely, toggles in C++ become an elegant tool, not a crutch.

Simplest implementation: from #define to runtime flags

The most primitive method, still found in legacy code:

#define USE_NEW_ALGORITHM 1\n\nvoid processImage(Image& img) {\n#if USE_NEW_ALGORITHM\n    // new fast algorithm\n    newCompress(img);\n#else\n    // old slow one\n    oldCompress(img);\n#endif\n}

The disadvantages are obvious: to switch, you need to edit the code and rebuild. Plus — zero flexibility. Don't even try doing this in production.

The right way is runtime flags. A minimal working version:

#include <atomic>\n#include <string>\n\nclass FeatureFlag {\npublic:\n    explicit FeatureFlag(bool enabled) : enabled_(enabled) {}\n    \n    bool isEnabled() const { return enabled_.load(); }\n    void setEnabled(bool val) { enabled_.store(val); }\n    \nprivate:\n    std::atomic<bool> enabled_{false};\n};\n\n// Global flag registry\nclass FeatureFlags {\npublic:\n    static FeatureFlag& get(const std::string& name) {\n        static std::unordered_map<std::string, FeatureFlag> flags;\n        auto it = flags.find(name);\n        if (it == flags.end()) {\n            it = flags.emplace(name, false).first;\n        }\n        return it->second;\n    }\n};

Usage:

if (FeatureFlags::get("new_compression").isEnabled()) {\n    newCompress(img);\n} else {\n    oldCompress(img);\n}

Already better. But there's a nuance: std::unordered_map with a mutex inside is not the best friend for high-load. And string keys on every if statement are questionable.

Advanced approach: enum flags and constexpr

For production code, I recommend a hybrid approach. Static identifiers at compile time, and values from a runtime config.

#include <array>\n#include <atomic>\n#include <cstdint>\n\nenum class Feature : uint8_t {\n    NewCompression,\n    ParallelProcessing,\n    EnhancedLogging,\n    ExperimentalParser,\n    COUNT  // always last\n};\n\nclass FlagManager {\npublic:\n    static FlagManager& instance() {\n        static FlagManager mgr;\n        return mgr;\n    }\n    \n    bool isEnabled(Feature f) const {\n