Используйте #ifndef _HEADER_H_ #define _HEADER_H_ в заголовках

Question

Используйте #ifndef _HEADER_H_ #define _HEADER_H_ в заголовках

0

Должен ли я использовать

#ifndef _HEADER_H_
#define _HEADER_H_

и т.д. в каждом файле заголовка?

kutsyk 06 дек. 2013, в 18:00

Источник

1

Нет, вы должны использовать тот же идентификатор. Оставляя опечатку в стороне, да, вы должны охранять каждый заголовок. Вы можете рассмотреть #pragma once в качестве альтернативы.
stefan 06 дек. 2013, в 16:32
1

Имена, начинающиеся со _HEADER_H подчеркивания, за которым следует заглавная буква ( _HEADER_H ), и имена, содержащие два последовательных _HEADER_H подчеркивания, зарезервированы для реализации. Не используйте их.
Pete Becker 06 дек. 2013, в 16:55

Теги:

c++

c

header

1 ответ

Ещё вопросы

Нет, вы должны использовать тот же идентификатор. Оставляя опечатку в стороне, да, вы должны охранять каждый заголовок. Вы можете рассмотреть #pragma once в качестве альтернативы.
Имена, начинающиеся со _HEADER_H подчеркивания, за которым следует заглавная буква ( _HEADER_H ), и имена, содержащие два последовательных _HEADER_H подчеркивания, зарезервированы для реализации. Не используйте их.

stefan · Accepted Answer · 2013-12-06T14-03-00.000Z

3

Лучший ответ

Да, это хорошая практика для защиты каждого заголовка. Существует два наиболее распространенных способа сделать это:

#ifndef UNIQUE_IDENTIFIER // the identifier musn't start with "_"!
#define UNIQUE_IDENTIFIER
// your code here
#endif

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

#pragma once
// your code here

stefan 06 дек. 2013, в 14:03

1

Я также видел комментарии о том, что однажды #pragma немного более эффективна, поскольку может предотвратить двойную загрузку одного и того же файла, в то время как традиционный подход все еще требует загрузки файла и обработки предохранителя включения.
Eric 06 дек. 2013, в 16:55
0

@Eric Да, я тоже об этом слышал. Afaik, это только когда-либо оказывается значительным с огромными заголовками. Поскольку я ограничиваю себя как можно меньшими заголовками (и думаю, что все должны), я никогда не смог измерить значительно лучшую производительность.
stefan 06 дек. 2013, в 16:57
0

@Eric Я не знаю ни одного компилятора, который не распознает включенные средства защиты и физически обращается к файлу только один раз, когда присутствует, независимо от того, используется ли классическое включение защиты или #pragma once .
IInspectable 06 дек. 2013, в 16:58
0

@IInspectable Хорошо, одна последняя попытка: #pragma once Once => 100% уверенность в том, что двойное включение запрещено. #ifndef / #define / #endif => дополнительные проверки, если нужна только одна. Вы серьезно не видите разницу?
stefan 06 дек. 2013, в 17:42
0

@stefan Компилятор создает AST. Он может легко распознать включенную охрану. Если он находит его, он просто помещает файл в тот же список, в который попадает файл #pragma once . Никаких дополнительных проверок не требуется. Нет разницы. Если вы по-прежнему видите разницу, напишите фронтэнд компилятора и посмотрите, не изменит ли это ваше мнение.
IInspectable 07 дек. 2013, в 01:36
0

@IInspectable Писание жирным шрифтом не сделает вас правым . Согласитесь, составители могут легко распознать включенную охрану. На этом этапе не имеет значения, если это ifndef или pragma , та же оптимизация. Тем не менее, это все же немного больше для анализа ifndef , identifier , define , identifier , ничего, что мешает identifier а затем endif а затем, никакому другому включению guard. #pragma once выражает намерение для пользователя и компилятора в одном простом выражении. Это даже легче обработать, чем включить защиту. Это все, что я когда-либо говорил.
stefan 07 дек. 2013, в 07:56

Показать ещё 4 комментария