Практика наличия «общего» заголовка

Question

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

Например, если у нескольких типов может быть Color, который является перечислением, вы бы хотели сделать его доступным. Некоторые люди скажут, чтобы поместить его в класс, с которым он «лучше всего подходит», но это может создать проблемы с зависимостями заголовка.

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

Answer 1

Я всегда использую файл Common.h, который почти никогда не изменяется и содержит определения, которые, скорее всего, понадобятся практически во всех файлах. Я думаю, что это повышает производительность, так что вам не нужно открывать другой файл .cpp и копировать список всех заголовков, которые вам наверняка понадобятся.

Например, вот две выдержки из моего Common.h:

typedef unsigned char uint8;
typedef signed char int8;
typedef unsigned char uint08;
typedef signed char int08;
typedef unsigned short uint16;
typedef signed short int16;
typedef unsigned int uint32;
typedef signed int int32;
typedef unsigned long long uint64;
typedef signed long long int64;
typedef const char cchar;
typedef const bool cbool;
typedef char Byte;

#ifdef ASSERT
/* Re-defining assert */
#undef ASSERT
#endif

#ifdef DEBUG
#ifndef ASSERTIONS
#define ASSERTIONS
#endif
#endif

#define ASSERT_ALWAYS(Expression)   if (!(Expression)) FatalError(ErrorInfo("Assertion Failure", #Expression, FUNCTION_NAME, __FILE__, __LINE__))

#ifdef ASSERTIONS
#ifdef DEBUG
#define ASSERT(Expression)   ASSERT_ALWAYS(Expression)
#else
#define ASSERT(Expression)   if (!(Expression)) ErrorLog("[Release Assertions]: The following assertion failed: " # Expression)
#endif
#else
#define ASSERT(Expression)
#endif

Answer 2

Общий заголовок в порядке, если над вашим проектом работает всего несколько человек. Когда у вас более 20 человек, которые редактируют этот файл и объединяют изменения назад и вперед, у вас начинается кошмар.

Возможно, альтернативой будет иметь файл color.h или common/color.h, который обеспечит некоторую структуру ваших файлов.

Answer 3

Лично я не фанат.

1. Я имею в виду, что когда вы изменяете константу (или тип), которая используется только в одном месте, вам нужно перекомпилировать весь ваш проект.
2. Значение константы (или определение типа) и использование упомянутой константы (или типа) находятся в двух разных местах.

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

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

Answer 4

Я предпочитаю четко указывать, что нужно каждому файлу cpp. Я обнаружил, что в конечном итоге это проще, и что он предотвращает перестроение файлов «общими» заголовками, когда в этом нет необходимости. По мере развития проекта наличие строгой политики «включай только то, что тебе нужно» может помочь сократить время сборки. О цене этого мало думают, когда вы изначально строите новый класс. У меня часто есть заголовочные файлы только для одного перечисления или typedef, и я даже дошел до того, что у меня есть специальная конфигурация сборки, которая собирается без предварительно скомпилированных заголовков и (поскольку я работаю с Visual Studio) использую #pragma hdrstop для определения моих предварительно скомпилированных заголовков вместо того, чтобы иметь каждый файл должен включать общий файл для этой цели.

На протяжении многих лет я обнаружил, что это очень хорошо работает для сокращения времени сборки и позволяет перемещать код (из библиотек или в другие проекты) или создавать для использования в тестах.

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

Answer 5

IMO Общие заголовки - это хорошая практика , если вы ограничиваете их содержанием вещей, которые редко меняются , таких как

typedef unsigned int UINT32;

Если вы часто редактируете этот файл, значит, в нем есть вещи, которых там нет.

Answer 6

Если вам нужны глобальные перечисления, поместите их в свое собственное пространство имен вместо того, чтобы загрязнять глобальное пространство имен, например ::10000

// Types.h

namespace MyTypes
{
    enum Color
    {
        RED,
        BLUE,
        GREEN,
    };
}

Лично я предпочитаю сохранять перечисления, связанные с классом, но YMMV.