Слишком много декларации и инициализации в заголовочном файле C++

Question

У меня есть файл Constants.h, в котором объявлено и инициализировано около 200 переменных (в основном массивов). Я использую пространство имен.

СПОСОБ 1:

//Constants.h 

#ifndef CONSTANTS_H_ 
#define CONSTANTS_H_ 

namespace LibConstants 
{ 
    const int a = 12; 
    const std::string theme[2]; = {"themeA", "themeB"}; 
    const int arr[2] = {1, 2}; 
    // and around 200 more declarations with initialization 
} 
#endif 

Этот .h файл почти каждый .cpp файл, но каждый раз, когда только очень минимальные переменные используется как LibConstants::theme[0]#include.

Мои способы работают нормально, но не он излишне выделяет память? Должен ли я следовать подходу, определять только переменные в файле .h и инициализировать его в .cpp?

Как и в ниже код: МЕТОД 2:

//Constants.h 

#ifndef CONSTANTS_H_ 
#define CONSTANTS_H_ 

namespace LibConstants { 

    std::string getMyTheme(int arg); 
    std::string getMyThemeName(int arg); 

    const int a; 
    const std::string theme[2]; 
    const int arr[2]; 
    // and around 200 more declarations with initialisation 
}; 
#endif 

Инициирование в CPP файле

//Constants.cpp 

#include LibConstants.h 
using namespace LibConstants { 
    std::string getMyTheme(int arg) { 
     theme[2] = {"themeA", "themeB"}; 
     return theme[arg]; 
    } 
    std::string getMyThemeName(int arg) { 
     ... 
    } 
} 

Используя его как

//HelloWorld.cpp 

#include Constants.h 
int main() { 
    //METHOD 1: 
    std::string a = LibConstants::theme[0]; // arg=0 is dynamic and is being read from localStorage in my case. 
    //METHOD 2: 
    std::string a = LibConstants::getMyTheme(0); //Here also arg=0 is dynamic. 
    ... 
} 

Здесь ненужное выделение памяти для ненужных переменных не произойдет, за исключением массивов, объявленных как const std::string st[2]; в файле заголовка.

Здесь «arg = 0» - это время выполнения. Имеет ли значение, если какая-либо переменная не зависит от времени выполнения, а только время компиляции, в этом случае она просто заменит значение placeholder в соответствующем файле .cpp?

Пожалуйста, исправьте меня везде, где я ошибаюсь.

Answer 1

Возьмите пример std::string. Рассмотрим,

namespace Constants { 
const std::string str = "A not very short string"; 
} 

str является тип класса, он имеет конструктор, и он должен выделить память для хранения его содержимого (если оптимизация короткая строка не используется в его реализации. Даже в этом случае, это относится только к, ну, «короткая строка»). Он объявлен переменной области пространства имен. Таким образом, программа должна создать эту переменную при запуске. Каждая программа, объявившая эту переменную, должна будет выделить память и инициализировать ее содержимое. Это накладные расходы, которые вы, вероятно, не хотите, в зависимости от того, насколько это повлияет на вашу производительность.

С другой стороны, если у вас есть,

const std::string &str() 
{ 
    const static std::string s = "A not very short string"; 

    return s; 
} 

Теперь у вас есть статический локальные переменный. Он будет инициализирован при первом входе функции. И он будет инициализирован только один раз. Если str никогда не вызывается, он не будет инициализирован вообще.

Однако обратите внимание, что строковый литерал "A not very short string" по-прежнему будет занимать некоторую память. Где и как это хранилище, определяется реализация. Обычно в сегментах данных, и воздействие обычно минимально.

В отличие от типов классов. Предпочтительно определять основные типы, особенно интегральные типы в заголовке.

Например,

namespace Constants { 
constexpr int x = 10; 
} 

оптимизирующий компилятор скорее всего не хранить переменную x и его содержимое 10 вообще. Вместо этого, где используется x, он будет заменен на 10 и в некоторых случаях закодирован в операционный код инструкции (так называемые непосредственные операнды). Конечно, это снова деталь реализации. И такую ​​оптимизацию нельзя использовать со всеми компиляторами. И если вы принимаете адрес x или в противном случае используется ODR, компилятор будет вынужден освободить место для этой переменной в любом случае. Но суть в том, что будет очень маловероятно, что вам будет хуже, объявив эти константы в заголовке, чем определяя его во внешнем исходном файле.