Feature flags в C++: управление фичами без боли и пересборки

Зачем C++ проектам feature flags? Разбираемся на практике

Представьте: вы пишете библиотеку для обработки изображений. Новая версия алгоритма сжатия даёт +30% к скорости, но требует доработки под конкретные архитектуры процессоров. Выпустить её сразу — рискованно. Не выпустить — теряете конкурентное преимущество. Знакомая дилемма?

В мире веб-разработки эту проблему давно решили с помощью feature flags (они же фича-тогглы или флаги функциональности). Но в C++ экосистеме к ним относятся настороженно: «Это же не PHP, у нас нативная компиляция, тут каждый if важен». И зря. Feature flags в C++ — это не про замедление, а про контроль. Давайте разберём, как внедрить их без боли, сохранив производительность и здравый смысл.

Что такое feature flags и почему они нужны именно в C++

Feature flag — это условное переключение, которое позволяет включать или выключать функциональность без изменения кода и перекомпиляции. В C++ это особенно актуально из-за специфики языка:

• Долгая сборка — перекомпилировать весь проект ради одного флага — дорогое удовольствие.
• Разные платформы — одна фича может работать на Linux и падать на Windows.
• А/B тестирование — хотите проверить новый парсер? Включите его для 5% пользователей.
• Канареечные релизы — раскатывайте фичи на малую аудиторию, не затрагивая всех.

Главный страх C++ разработчиков — что флаги засорят код и убьют производительность. Но если подойти с умом, тогглы в C++ становятся элегантным инструментом, а не костылём.

Простейшая реализация: от #define к runtime-флагам

Самый примитивный способ, который до сих пор встречается в legacy-коде:

#define USE_NEW_ALGORITHM 1

void processImage(Image& img) {
#if USE_NEW_ALGORITHM
    // новый быстрый алгоритм
    newCompress(img);
#else
    // старый медленный
    oldCompress(img);
#endif
}

Минусы очевидны: чтобы переключить, нужно править код и пересобирать. Плюс — ноль гибкости. Даже не пытайтесь так делать в production.

Правильный путь — runtime-флаги. Минимальная рабочая версия:

#include <atomic>
#include <string>

class FeatureFlag {
public:
    explicit FeatureFlag(bool enabled) : enabled_(enabled) {}
    
    bool isEnabled() const { return enabled_.load(); }
    void setEnabled(bool val) { enabled_.store(val); }
    
private:
    std::atomic<bool> enabled_{false};
};

// Глобальный реестр флагов
class FeatureFlags {
public:
    static FeatureFlag& get(const std::string& name) {
        static std::unordered_map<std::string, FeatureFlag> flags;
        auto it = flags.find(name);
        if (it == flags.end()) {
            it = flags.emplace(name, false).first;
        }
        return it->second;
    }
};

Использование:

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

Уже лучше. Но есть нюанс: std::unordered_map с мьютексом внутри — не лучший друг для high-load. Да и строковые ключи на каждом if — сомнительное удовольствие.

Продвинутый подход: enum-флаги и constexpr

Для production-кода я рекомендую гибридный подход. Статические идентификаторы на этапе компиляции, а значения — из runtime-конфига.

#include <array>
#include <atomic>
#include <cstdint>

enum class Feature : uint8_t {
    NewCompression,
    ParallelProcessing,
    EnhancedLogging,
    ExperimentalParser,
    COUNT  // всегда последним
};

class FlagManager {
public:
    static FlagManager& instance() {
        static FlagManager mgr;
        return mgr;
    }
    
    bool isEnabled(Feature f) const {
        return flags_[static_cast<size_t>(f)].load(std::memory_order_relaxed);
    }
    
    void setEnabled(Feature f, bool val) {
        flags_[static_cast<size_t>(f)].store(val, std::memory_order_relaxed);
    }
    
    // Загрузка из JSON/YAML
    void loadFromConfig(const std::string& path);
    
private:
    static constexpr size_t COUNT = static_cast<size_t>(Feature::COUNT);
    std::array<std::atomic<bool>, COUNT> flags_{};
};

Почему это круто:

• Без блокировок — std::atomic<bool> работает быстрее мьютексов.
• Размер известен на этапе компиляции — массив лежит на стеке.
• Enum не даст ошибиться в имени — компилятор поймает опечатку.
• Memory order relaxed — для флагов нам не нужна строгая синхронизация.

Использование в коде становится лаконичным:

if (FlagManager::instance().isEnabled(Feature::NewCompression)) {
    // новая логика
}

Теперь давайте посмотрим, как это выглядит в реальном проекте на примере управления фичами в C++ для библиотеки парсинга.

Живой пример: A/B тестирование алгоритма парсинга

Допустим, у нас есть парсер CSV-файлов. Мы хотим протестировать новый токенизатор, но только на 10% пользователей. Вот как это реализовать с помощью флагов функциональности C++:

#include <random>
#include <string>

// Наш enum расширяется
enum class Feature : uint8_t {
    NewTokenizer,
    // ... другие фичи
    COUNT
};

class ABTestManager {
public:
    static bool isInTestGroup(const std::string& userId, Feature f, double percent) {
        // Детерминированный хеш от userId + имя фичи
        std::hash<std::string> hasher;
        size_t hash = hasher(userId + featureName(f));
        
        return (hash % 100) < static_cast<size_t>(percent * 100);
    }
    
private:
    static std::string featureName(Feature f) {
        switch(f) {
            case Feature::NewTokenizer: return "new_tokenizer";
            default: return "unknown";
        }
    }
};

В коде парсера:

CSVRow parseLine(const std::string& line, const std::string& userId) {
    if (ABTestManager::isInTestGroup(userId, Feature::NewTokenizer, 0.1)) {
        return newTokenizer.parse(line);
    }
    return oldTokenizer.parse(line);
}

Красота в том, что мы не меняем сигнатуру функции, не трогаем тесты для старого парсера. Просто добавляем условие. А когда новый токенизатор подтвердит эффективность — убираем старый код и флаг.

Как не выстрелить себе в ногу: best practices

За годы работы с тогглами в C++