2016-08-30 11 views
2

Только вопрос стиля, или, возможно, даже халатности, о котором я не знаю.C++ Library Inclusion Guards

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

Например

exampleClass.h

#ifndef BUG_H 
#define BUG_H 
#include<string> 

class Bug{ 
private: 
    int bug_id; //6 digit int 
    Date creation_ts; //Date object containing time of creation 
    std::string short_desc; //Short description of bug 
    std::string classification; //Catagory of bug_id 
    std::string product; //What product is the bug regarding 
    std::string component 
} 

#endif 

anotherExample.h

#ifndef ANOTHEREXAMPLE_H 
#define ANOTHEREXAMPLE_H 
#include<string> 

class Pug{ 
private: 
    int bug_id; //6 digit int 
    Date creation_ts; //Date object containing time of creation 
    std::string short_desc; //Short description of bug 
    std::string classification; //Catagory of bug_id 
    std::string product; //What product is the bug regarding 
    std::string component 
} 

#endif 

Есть ли что-нибудь неправильно с включением строку дважды в двух различных файлах, если оба имеют зависимости? Это приведет к ошибкам в дальнейшем в жизни программного обеспечения?

+0

Это очень вероятно, что '' имеет свой собственный [* заголовок * включают охрану] (https://en.wikipedia.org/вики/Include_guard). –

ответ

2

Если эти два файла не связаны друг с другом, например, не включены оба в один и тот же источник, тогда у вас нет выбора. В противном случае это не имеет большого значения, поскольку <string> все равно будет включен, если вы включили один файл за другим. Один из файлов все равно понадобится. Но все же, если в одном файле когда-либо нужен файл, включите его в комплект ALWAYS. Всегда есть риск, что однажды кто-то может забыть включить другой файл, и код не будет компилироваться. Не рискуйте, доверяя клиентам.

Кроме того, у std::string есть и охранники, поэтому вам не нужно беспокоиться о множественном включении. Кроме того, для обеспечения безопасности включения, вы можете сделать это Fr ваши заголовки:

#pragma once 
#ifndef HEADER_H 
#define HEADER_H 
//.....Code 
#endif 

Вы могли всегда #pragma или #define, (как в 1 или другой), но положить обе гарантии заголовка охранников, так как старые компиляторы Дон» t support #pragma once

+0

Вопрос был отредактирован после того, как вы дали ответ? В настоящее время я не очень понимаю этот вопрос и не понимаю, почему вы объясняете, включают ли охранники, когда у них есть OP – user463035818

+0

. Это просто нерелевантная информация, чтобы гарантировать, что OP не беспокоится о ошибках определения dobule или ошибках с двойным включением @ tobi303 –

+0

hm ok. Я имею в виду, что если вопрос не был отредактирован, кажется, что OP использовал их, не понимая их цели, и ваше объяснение вообще не имеет значения. – user463035818

1

Есть ли что-то не так с включением строки дважды в два разных файла заголовка, если у обоих есть зависимости? Это приведет к ошибкам в дальнейшем в жизни программного обеспечения?

Нет, в самом деле, вы должны включать каждый заголовочный файл, который вы на самом деле есть зависимость. Вы не должны полагаться на какой-либо другой заголовок, который включает вашу зависимость. Невозможно включить все необходимые заголовки, которые вызывают ошибки. Если ваш класс нуждается в std::string, он должен включать <string>. Период.

Все заголовки должны включать в себя защитные приспособления (из или #pragma once). Конечно, те, что реализованы в вашей стандартной библиотеке. Таким образом, недостаток дополнительных включает в себя лишь незначительное дополнительное время предварительной обработки, при этом гарантируется скомпилирование кода.

1

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

BTW есть лучший способ, чем ifdefs, чтобы избежать многократных включений:

#pragma once 
+0

Также см. [Почему не C/C++ «#pragma once» стандарт ISO?] (Http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard) –