Шаблон C ++ только для заголовков - PullRequest
2 голосов
/ 13 октября 2011

Я хотел бы написать код в .hpp без разделения на .h и .cpp

  • Я сделал это.Я использую .cpp только для статических определений полей классов

Я бы не хотел писать #include вручную ...

  • Я использую forwardкогда это возможно.
  • Каждый мой файл .hpp содержит один раз #pragma.
  • Но когда мой проект вырос до 40-50 классов, я увидел проблему включения графа.Есть некоторые ошибки определений.

Изображение с приложенным графиком модели моего проекта (как часть mvc).Я использовал это приложение для генерации графиков (может работать без MSVS!).

include graph

Как должен выглядеть график включения?Как дерево?Как не писать включает вручную, как в C # или Java?

Ответы [ 4 ]

11 голосов
/ 13 октября 2011

К сожалению, вы, возможно, используете не тот язык. Есть некоторые вещи, которые намного проще в C ++, когда вы отделяете определение класса от реализации. Даже с предварительными объявлениями вы, вероятно, по-прежнему будете иметь циклические зависимости, которые могут быть разрешены только путем перемещения реализаций в отдельные файлы.

Если вы хотите написать идиоматическую Java, просто напишите ее на Java. Если вы хотите использовать язык C ++, к сожалению, вам придется работать в рамках его ограничений.

1 голос
/ 13 октября 2011

Я настоятельно рекомендую помещать реализацию в файлы ".cpp" и объявления или интерфейс в файлы заголовков ".hpp".

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

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

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

Не беспокойтесь ни о количестве файлов, ни о продолжительности процесса сборки. Сосредоточиться на завершении проекта правильно, надежно и в соответствии с графиком. Настройте процесс сборки по мере необходимости. Если в расписании много времени, если код работает правильно и надежен, внесите изменения. Если изменение процесса сборки может значительно ускорить время разработки *, внесите изменения.

1 голос
/ 13 октября 2011

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

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

Код только для заголовка имеет смысл, только если выВ основном, мы проектируем библиотеку на основе шаблонов, потому что шаблон должен находиться в заголовках.См. boost template library, например.Кроме того, следует отметить, что в реальном приложении, использующем библиотеки шаблонов, все еще есть эти .cpp файлы для их кода, и именно здесь экземпляры шаблонов фактически «используются».

1 голос
/ 13 октября 2011

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

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

...