C++ Singleton Constructor and Destructor

Question

Имеет ли значение, реализована ли реализация конструктора/деструктора в файле заголовка или в исходном файле? Например, какой путь является предпочтительным и почему?

Способ 1:

class Singleton 
{ 
    public: 
    ~Singleton() { } 

    private: 
    Singleton() { } 
}; 

Способ 2:

class Singleton 
{ 
    public: 
    ~Singleton(); 

    private: 
    Singleton(); 
}; 

В исходном файле .cc:

Singleton::Singleton() 
{ 
} 

Singleton::~Singleton() 
{ 
} 

Изначально у меня есть осуществление в исходном файле, но Меня попросили удалить его. Кто-нибудь знает, почему?

Answer 1

Это не имеет значения, но, как правило, лучше (в моих скромных мнениях) определить их в .cpp-файле, чтобы скрыть реализацию от пользователей этого класса.

Answer 2

Если функция определена в файле заголовка (то есть тело функции находится в файле заголовка), то компилятор может выбрать inline функцию в качестве оптимизации. Если функция определена в исходном файле, компилятор не может ее встроить. Помимо этого, на самом деле нет никакой разницы.

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

Вообще говоря, если у вас есть короткая функция, которая, по вашему мнению, имеет хорошие шансы быть встроенной, то это хорошая идея поместить ее в заголовочный файл, чтобы компилятор мог сделать эту оптимизацию. В противном случае лучше поместить его в исходный файл, где он не загромождает вещи. И в идеале, заголовочный файл показывает API, а не реализацию, в любом случае.

Что касается конструктора и деструктора singleton, они будут вызываться только один раз во всей программе, поэтому вы не получите ничего, вложив их в них, чтобы вы могли также вставлять их в исходный файл, если вы делая многое из них. Но если они пусты, зачем тратить пространство в исходном файле? Просто поместите их в файл заголовка.

Answer 3

Отличие состоит в том, что добавление реализации непосредственно в класс заставляет функцию быть встроенной.

Answer 4

Это имеет значение несколькими тонкими способами. функции, определенные в файле заголовка (ваш «путь 1») могут (в моем опыте, как правило,) быть объявлены встроенными (хотя, как и в inline, если функция велика, она не может быть встроена компилятором). Это может вызвать проблемы, особенно при работе с абстрактными классами.

Причина этого заключается в том, что vtable будет включен в блок компиляции (файл .o), где будет найдена первая не-встроенная функция. Если все функции встроены, v-таблица не будет найдена, и ваш код не будет связан. (Есть способы обойти это, но для другой темы.)

Итак, используйте способ 2 для более организованного кода, особенно для классов с множеством функций-членов и/или длинными функциями-членами, а также в случаях, когда у вас есть наследование и виртуальные функции, плавающие вокруг. Используйте путь 1 для очень коротких классов (где весь заголовочный файл будет меньше, чем около 100-200 строк).

Answer 5

Выбор в значительной степени стилистический, поскольку функция inlining может или не может вступить в игру.Да, все в заголовочном файле может получить вставку, но, скорее всего, все, что вы знаете о встроенной функции, неверно. Я знаю, что все, что я знаю об использовании, неверно, поскольку вы просто не можете выбрать, что сделает компилятор. Поэтому я бы не стал беспокоиться об этом аспекте в этом случае.

Существует, однако, еще одна тонкость, которую мы можем исследовать здесь. Скажем, конструктор в классе Singleton является публичным:

class Singleton 
{ 
public: 
    Singleton(void); 
    virtual ~Singleton(void); 
}; 
//cpp file 
Singleton::Singleton() 
{ 
} 


Singleton::~Singleton() 
{ 
} 

Если поставить выше код в статическую библиотеку, что у вас есть, по существу, класс, который не может не быть реализован за пределами библиотеки. Это не будет компилятор, который помешает вам сделать это, но компоновщик. Это ошибка, вы получите:

1> testrun.obj: ошибка LNK2001: неразрешенный внешний символ "общественности: виртуальный __thiscall Singleton :: ~ Singleton (аннулируются)" (?? 1Singleton @@ UAE @ XZ)
1> testrun.obj: ошибка LNK2001: неразрешенный внешний символ "public: __thiscall Singleton :: Singleton (void)" (?? 0Singleton @@ QAE @ XZ)
1> C: \ temp \ sotest \ Debug \ testrun .exe: фатальная ошибка LNK1120: 2 нерешенных внешних