Базовое понимание файлов заголовков C ++
У меня вопрос теории, а не отчет об ошибке.
Я Я новичок в программировании на C ++, пытаюсь продвинуть это далеко
Используя компилятор VC ++ VS2008
Я часто задаюсь вопросом, ПОЧЕМУ я хочу выполнить некоторые действия в файлах заголовков.
Например, посмотрите на этот блок кода :
#include "DrawScene.h"
#include "Camera.h"
#include "Player.h"
#include "Grid.h"
#include "InputHandler.h"
#include "GameState.h"
class Controller
{
public:
private:
public:
Controller();
~Controller(){}
void Update();
private:
};
И подключенный файл CPP, контроллер. cpp вместе с ним
#include "stdafx.h"
#include "glut.h"
#include "Controller.h"
#include <iostream>
Grid* grid_ptr = new Grid();
InputHandler* inputHandler_ptr = new InputHandler();
DrawScene* drawScene_ptr = new DrawScene();
GameState* gameState_ptr = new GameState();
Controller::Controller()
{
}
void Controller::Update()
{
}
Какой хороший способ решить, что включает, куда идти? До сих пор я использовал метод «все, что работает», но считаю его несколько непрофессиональным.
Теперь, даже если вы можете сказать, что в моем коде есть X-синтаксические ошибки и недостатки дизайна, пожалуйста, сделайте это, но я был бы признателен за то, что информация остается об использовании файлов .h VS.cpp.
Почему они вообще существуют. такой дизайн? И какие ямы и ловушки нужно всегда осторожно обходить при создании любой программы на C ++ на основе ООП?
Что вызвало у меня этот вопрос, кстати, это то, что я хотел уведомить читателя файла заголовка о том, что будут храниться объекты в контроллере, но назначение этих неинициализированных объектов казалось невозможным, не делая их статичными.
Примечание: я произошел от C # -> C ++, может помочь узнать. Который' в некотором роде мой взгляд на код на данный момент.
Заранее благодарю вас за ваши усилия!
РЕДАКТИРОВАТЬ: 26/08/2010 18:16
Итак, время сборки - это суть хороших включений. Есть ли что-то еще, о чем следует быть осторожным?
5 ответов
В общем случае заголовки должны находиться в файле cpp. Для стандартной библиотеки (и, возможно, третьей библиотеки) вы можете вставить их в заголовки. Однако заголовки, определенные специально для вашего проекта, должны по возможности помещаться в файлы cpp.
Причина этого — время компиляции и проблемы с зависимостями.Каждый раз, когда вы меняете заголовочный файл, компилятору придется перекомпилировать каждый исходный файл, который его включает. Когда вы включаете файл заголовка в другой файл заголовка, компилятор должен перекомпилировать каждый файл cpp, который включает любой файл заголовка.
Вот почему так популярны опережающее объявление и шаблон PIMPL (указатель на IMPLementation или непрозрачный указатель). Это позволяет вам вынести хотя бы часть изменений/реализаций из заголовочного файла. Например:
// header file:
class SomeType;
class AnotherType
{
private:
SomeType *m_pimpl;
};
не требует включения "sometype.h", тогда как:
// header file
class AnotherType
{
private:
SomeType m_impl;
};
включает. РЕДАКТИРОВАТЬ: На самом деле вам не нужно включать «sometype.h» в «anothertype.h», если вы ВСЕГДА включаете «sometype.h» перед «anothertype.h» в КАЖДОМ файле cpp, который включает «anothertype.h».
Иногда бывает сложно переместить файл заголовка в файл cpp. В этот момент у вас есть решение — лучше ли попытаться абстрагировать код, чтобы вы могли это сделать, или лучше просто добавить включение?
Это мое личное мнение, а не согласованная передовая практика, но я рекомендую следующее: в файл заголовка включать только те заголовки, которые необходимы для компиляции содержимого файла заголовка без синтаксиса. ошибки. И если вы можете использовать предварительные объявления вместо вложенных включений, сделайте это.
Причина этого в том, что в C++ (в отличие от C#, iiuc) нет экспортного контроля. Все, что вы включаете из заголовка, будет видно включателям заголовка, что может быть большим количеством мусора, который пользователи вашего интерфейса не должны видеть.
Заголовочные файлы содержат объявления функций, классов и других объектов, тогда как файлы cpp предназначены для реализации этих ранее объявленных объектов.
Заголовочные файлы существуют главным образом по историческим причинам. Легче создать компилятор C++, если определения всех функций, классов и т. д., которые будут использоваться вашим кодом, даны до того, как вы их на самом деле вызовете.
Обычно для реализации вы используете cpp. Реализация функций в файлах заголовков автоматически встраивает их, поэтому, если они не очень маленькие и/или не вызываются очень часто, обычно это не то, что вам нужно.
Избегайте указывать слишком много ( читайте, всякое лишнее) #includes в вашем .h файле. Это может привести к длительному времени сборки, например. всякий раз, когда вы изменяете Camera.h, вы изменяете Controller.h, поэтому все, что включает Controller.h, необходимо будет перестроить. Даже если изменился только комментарий.
Используйте предварительные объявления, если вы храните только члены-указатели, а затем добавьте #includes в файл cpp.
Теоретически файлы .h содержат только интерфейс, а файлы .cpp — реализацию. Однако, поскольку закрытые члены, возможно, являются реализацией, а не интерфейсом, это не совсем так, поэтому необходимо предварительное объявление, чтобы свести к минимуму ненужные перестроения.
В C++ можно включить всю реализацию встроенно в определение класса, файл, как и в Java, но это действительно нарушает правило интерфейса/реализации .h/.cpp.
Включайте заголовки в другой заголовок только в случае крайней необходимости. Если заголовок может находиться исключительно в исходном файле, то это лучшее место.Вы можете использовать предварительные объявления классов в заголовке, если вы используете только указатели и ссылки на них. Ваши классы DrawScene, GameState, Grid и InputHandler могут попасть в эту категорию.
Обратите внимание, что C++ как язык не различает заголовки и исходные файлы. Это просто чрезвычайно распространенная система, используемая разработчиками для поддержки своего кода. Очевидное преимущество использования заголовков заключается в том, что они позволяют избежать дублирования кода и в некоторой степени помогают обеспечить соблюдение правила одного определения для классов, шаблонов и встроенных функций.