Feature flags em C++: gerenciamento de funcionalidades sem dor e sem recompilação

Por que projetos C++ precisam de feature flags? Entendendo na prática

Imagine: você está escrevendo uma biblioteca para processamento de imagens. A nova versão do algoritmo de compressão oferece +30% de velocidade, mas requer ajustes para arquiteturas específicas de processadores. Lançá-la imediatamente é arriscado. Não lançá-la significa perder vantagem competitiva. Dilema familiar?

No mundo do desenvolvimento web, esse problema foi resolvido há muito tempo com feature flags (também conhecidos como feature toggles ou flags de funcionalidade). Mas no ecossistema C++, eles são vistos com desconfiança: "Isso não é PHP, temos compilação nativa, cada if aqui é importante". E é um erro. Feature flags em C++ não são sobre lentidão, mas sobre controle. Vamos entender como implementá-los sem dor, preservando desempenho e bom senso.

O que são feature flags e por que são necessários especificamente em C++

Feature flag é uma chave condicional que permite ativar ou desativar funcionalidades sem alterar código e recompilar. Em C++, isso é especialmente relevante devido às especificidades da linguagem:

\n
• Compilação longa — recompilar todo o projeto por causa de uma flag é caro.
\n
• Plataformas diferentes — uma funcionalidade pode funcionar no Linux e falhar no Windows.
\n
• Teste A/B — quer testar um novo parser? Ative-o para 5% dos usuários.
\n
• Lançamentos canários — distribua funcionalidades para uma pequena audiência sem afetar todos.
\n

O principal medo dos desenvolvedores C++ é que as flags poluam o código e matem o desempenho. Mas se abordado com inteligência, os toggles em C++ se tornam uma ferramenta elegante, não uma gambiarra.

Implementação mais simples: de #define para flags em runtime

A maneira mais primitiva, que ainda é encontrada em código legado:

#define USE_NEW_ALGORITHM 1\n\nvoid processImage(Image& img) {\n#if USE_NEW_ALGORITHM\n    // novo algoritmo rápido\n    newCompress(img);\n#else\n    // antigo lento\n    oldCompress(img);\n#endif\n}

As desvantagens são óbvias: para alternar, é preciso editar o código e recompilar. Além disso, zero flexibilidade. Nem tente fazer isso em produção.

O caminho correto são as flags em runtime. Versão mínima funcional:

#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// Registro global de flags\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};

Uso:

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

Já é melhor. Mas há um detalhe: std::unordered_map com mutex interno não é o melhor amigo de high-load. Além disso, chaves de string em cada if é questionável.

Abordagem avançada: flags com enum e constexpr

Para código de produção, recomendo uma abordagem híbrida. Identificadores estáticos em tempo de compilação, e valores vindos de configuração em runtime.

#include <array>\n#include <atomic>\n#include <cstdint>\n\nenum class Feature : uint8_t {\n    NewCompression,\n    ParallelProcessing,\n    EnhancedLogging,\n    ExperimentalParser,\n    COUNT  // sempre por último\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