Usando uma variável estática de escopo de namespace como parâmetro padrão de função

É seguro usar uma variável estática de escopo de namespace (ou seja, ligação interna) como parâmetro padrão para uma função declarada em um cabeçalho? E se sim, é garantido que ao fazer uma chamada padrão em uma determinada unidade de tradução, o valor definido naquela unidade de tradução seja usado como padrão?

Em código:

biblioteca.h:

#pragma once

#ifdef USE_ALTERNATE_DEFAULT
static const int defaultValue = 42;
#else
static const int defaultValue = 314;
#endif

void printValue(int value = defaultValue);

biblioteca.cpp:

#include "lib.h"

#include <print>

void printValue(const int value) {
  std::println("Value: {}", value);
}

a.cpp:

#include "lib.h"

void foo() {
  printValue(); // '314'
  printValue(0); // '0'
}

b.cpp:

#define USE_ALTERNATE_DEFAULT

#include "lib.h"

void bar() {
  printValue(); // '42'
  printValue(1); // '1'
}

O código acima está bem formado? E é garantido que cada uma das chamadas para printValueresulte no valor no comentário correspondente sendo impresso?

Tenha em mente que lib.cpp, a.cpp e b.cpp podem fazer parte de diferentes bibliotecas/binários compartilhados.

O objetivo aqui é tornar o comportamento padrão de uma função personalizável em um nível por TU alterando as diretivas do pré-processador.

Contexto para a pergunta

Dito isto, a solução parece um tanto complicada e este pode ser um problema XY.

Aqui está uma descrição mais completa do que estou tentando fazer:

• Estou usando algo semelhante para bin2cgerar vários arquivos de cabeçalho que definem várias strings longas diferentes.
• Tenho uma biblioteca vinculada estaticamente libque precisa executar alguma operação nessas strings geradas automaticamente ou retornar à operação em uma string padrão caso nenhum cabeçalho desse tipo esteja disponível.
• Estou compilando várias versões diferentes de vários binários diferentes, cada um com diferentes arquivos de cabeçalho gerados automaticamente, cada um vinculado à lib.

Então lib.hpode ser algo como:

#ifdef GENERATED_HEADER
// static const char* kMyString defined in the generated header
#include GENERATED_HEADER
#else
// Define fall-back default.
static const char* kMyString = "default";
#endif

void doStuff(int someArg, const char* str = kMyString);

E claro lib.cpptem a definição de doStuff. Suponha que esta seja uma função complexa.

Então my_app1.cpp:

#include "lib.h"

int main() {
  int someArg = foo();
  doStuff(someArg);
}

E my_app2.cpp:

#include "lib.h"

int main() {
  int someArg = bar();
  doStuff(someArg);
}

Então:

• Compilar lib.cppem lib.a.
• Gerar Doc1.husando doc1.txtbin2c-ish.
• Gerar Doc2.husando doc2.txtbin2c-ish.
• Gerar Doc3.husando doc3.txtbin2c-ish.
• Compilar my_app1.cppe my_app1_default.avincular com lib.ainto my_app1_default.
• Compilar my_app1.cppcom -DGENERATED_HEADER=\"Doc1.h\"into my_app2_doc1.ae vincular com lib.ainto my_app1_doc1.
• Compilar my_app1.cppcom -DGENERATED_HEADER=\"Doc2.h\"into my_app1_doc2.ae vincular com lib.ainto my_app1_doc2.
• Compilar my_app2.cppe my_app2_default.avincular com lib.ainto my_app2_default.
• Compilar my_app2.cppcom -DGENERATED_HEADER=\"Doc3.h\"into my_app2_doc3.ae vincular com lib.ainto my_app2_doc3.

O ponto é que o comportamento de libpode ser personalizado em um nível por binário com base no ambiente de construção, enquanto ainda mantém uma única implementação de lib. E, além disso, libpode ser usado em vários códigos-fonte de aplicativos diferentes com código boilerplate mínimo.

Claro, se a abordagem do argumento padrão for malformada, aproximadamente a mesma coisa ainda pode ser alcançada simplesmente passando explicitamente a variável estática para a função. Mas isso exigiria um pouco mais de boilerplate no local da chamada, o que estou tentando evitar. Daí a pergunta acima :)