Magic numbers - jak przechowywać

Część,
Jaka jest naturalna konwencja przechowywania Magic Numbers?

const int return_repeats(1);
const QString file_path("C:/windows/system32/");
const double ratio(0.23) 

czy

enum { //dla intów
return_repeats =1,
rectangle_radius = 40,
port_size = 30
} 

czy

namespace {
const int return_repeats(1);
const QString file_path("C:/windows/system32/");
const double ratio(0.23)
};

Wyżej wymieniony kod pojawia się na poczatku pliku cpp, przed realizacją klas/funkcji.
enumy mają sens tylko dla intów, stringi i inne stałe tam nie wrzucę.
Globalnie trzymanie QString/std::string w cpp niczym nie grozi (inne pliki/translation units ich nie zobaczą).
DEFINEs i makr nawet nie wspomnę.

jeżeli są to stałe, ładowane raz na początku programu, możesz zastosować config ładowany z pliku lub database

boost::property_file - zgadzam się.
Załadować na początku i dependency inject do wszystkich potrzebujących przekazywać.

Sęk w tym, że niektóre z nich są i pozostaną stałe. Wiec pchać je do XML/JSON/INI ... czy to ma sens? Poniekąd ujawniasz część trzewi aplikacji użytkownikowi.

Korba napisał(a):

boost::property_file - zgadzam się.
Załadować na początku i dependency inject do wszystkich potrzebujących przekazywać.

Sęk w tym, że niektóre z nich są i pozostaną stałe. Wiec pchać je do XML/JSON/INI ... czy to ma sens? Poniekąd ujawniasz część trzewi aplikacji użytkownikowi.

nie, nie ma.

Inicjalizacja stałych w cpp jest ok.

I bym nie panikował, że ktoś będzie Ci grzebał w configu.

Jak pogrzebie i zepsuje to wtedy będzie ból.

Korba napisał(a):

Część,
Jaka jest naturalna konwencja przechowywania Magic Numbers?

const int return_repeats(1);
const QString file_path("C:/windows/system32/");
const double ratio(0.23) 

czy

enum { //dla intów
return_repeats =1,
rectangle_radius = 40,
port_size = 30
} 

czy

namespace {
const int return_repeats(1);
const QString file_path("C:/windows/system32/");
const double ratio(0.23)
};

Wyżej wymieniony kod pojawia się na poczatku pliku cpp, przed realizacją klas/funkcji.
enumy mają sens tylko dla intów, stringi i inne stałe tam nie wrzucę.
Globalnie trzymanie QString/std::string w cpp niczym nie grozi (inne pliki/translation units ich nie zobaczą).
DEFINEs i makr nawet nie wspomnę.

A właśnie że grozi. Konfliktem symboli podczas linkowania (zwłaszcza, że nazwy tych stałych nie wyglądają na unikalne).
Takie stałe widziane w zasięgu tylko modułu powinny być definiowane ze słowem kluczowym static (szczególnie jeśli robisz to w globalnym namespace).

Co do trzymania konfiguracji w Qt to od tego masz QSettings.

Podobno globalny (anonimowy namespace) czyni jego elementy staticami (link).
Surowe zmienne, bez dodatku statica - masz rację, mogą się kompilatorowi nie spodobać. So external linkage by default.

const QString file_path("C:/windows/system32/");

Zacznijmy od tego, że hardkodowanie ścieżki to błąd. Trzeba ją pobrać z systemu.