Verwenden eines Namespace-Scope-statischen Variablen als Funktion Standardparameter ⇐ C++

[Anonymous]

Ist es sicher, eine statische Variable (d. H. Interne Verknüpfung) als Standardparameter für eine in einem Header deklarierte Funktion zu verwenden? Und wenn ja, ist es garantiert, dass bei einem standardmäßigen Aufruf in einer bestimmten Übersetzungseinheit der in dieser Übersetzungseinheit definierte Wert als Standard verwendet wird?

Code: Select all

#pragma once

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

void printValue(int value = defaultValue);
< /code>
lib.cpp:
#include "lib.h"

#include

void printValue(const int value) {
std::println("Value: {}", value);
}
< /code>
a.cpp:
#include "lib.h"

void foo() {
printValue(); // '314'
printValue(0); // '0'
}
< /code>
b.cpp:
#define USE_ALTERNATE_DEFAULT

#include "lib.h"

void bar() {
printValue(); // '42'
printValue(1); // '1'
}
< /code>
Ist der Code oben gut geformt? Und ist es garantiert, dass jeder der Aufrufe zum PrintValue < /code> dazu führt, dass der Wert im entsprechenden Kommentar gedruckt wird? Direktiven. /> [*] Ich verwende etwas Ähnliches wie Bin2c 

, um verschiedene Header-Dateien zu generieren, die verschiedene lange Zeichenfolgen definieren. Mit verschiedenen automatisch generierten Header-Dateien, die jeweils mit lib.

Code: Select all

#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);

und natürlich lib.cpp hat die Definition von dostuff . Angenommen, dies ist eine komplexe Funktion.
Dann my_app1.cpp :

Code: Select all

#include "lib.h"

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

und my_app2.cpp :

Code: Select all

#include "lib.h"

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

Dann:

• kompilieren Sie lib.cpp in lib.a . doc2.txt Verwenden von Bin2c-ish. my_app1_default . my_app1.cpp mit -dGenerated_Header = \ "doc2.h \" in my_app1_doc2.a und link mit lib.a in my_app1_doc2 . lib.a in my_app2_default .
  kompilieren Sie my_app2.cpp mit -dGenerated_Header = \ "doc3.h \" in my_app2_doc3.a und Link mit lib.a in my_app2_doc3

Der Punkt ist, dass das Verhalten von lib basierend auf der Build-Umgebung auf einer Binärebene angepasst werden kann und gleichzeitig eine einzige Implementierung von lib beibehalten wird. Darüber hinaus kann Lib ini mehreren verschiedenen Anwendungen mit minimalem Boilerplate-Code verwendet werden. Aber das würde ein bisschen mehr Kesselplatten an der Call-Site erfordern, die ich vermeiden möchte. Daher die obige Frage