Файл шаблона (.tpp) включает защиту
При написании шаблонных классов мне нравится перемещать реализацию в другой файл (myclass.tpp) и включать ее в конец основного заголовка (myclass.hpp).
Мой вопрос: нужно ли мне включать охранники в файл .tpp или достаточно, чтобы они были в файле .hpp?
Пример кода:
myclass.hpp
#ifndef MYCLASS_HPP
#define MYCLASS_HPP
template<typename T>
class MyClass
{
public:
T foo(T obj);
};
//include template implemetation
#include "myclass.tpp"
#endif
myclass.tpp
#ifndef MYCLASS_TPP //needed?
#define MYCLASS_TPP //needed?
template<typename T>
T MyClass<T>::foo(T obj)
{
return obj;
}
#endif //needed?
Я бы пошел еще дальше и добавил описательную директиву #error, если защита hpp не определена. Просто чтобы немного защитить от людей, в том числе от tpp.
Ваш .tpp будет включен другими? если нет (я думаю), то зачем его охранять?
в противном случае это может быть использовано для дополнительного включения функций .tpp (пользователем), тогда требуется защита (но я бы сказал, что лучше использовать .hpp)
плюс я не думаю, что кто-то будет напрямую включать .tpp, как и .cpp
Возможно, вы сможете заменить все эти защитные средства на #pragma once, поскольку он широко поддерживается.
@quamrana Гарды лучше #pragma once во всем. Нет причин помещать нестандартную версию в новый код.
Ответы 2
Do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?
Включение охранников никогда не бывает нужный: они просто ужасно полезны, дешевы, не нарушают работу и ожидаемы. Так что да, вы должны защитить оба файла с помощью защиты заголовков:
- Ужасно полезно: они позволяют объявить зависимость от нескольких файлов, не отслеживая, какие файлы уже были включены.
- Дешевый: это всего лишь некоторые токены прекомпиляции.
- Неразрушающий: они хорошо подходят для большинства вариантов использования
#include(у меня был коллега, который не умел писать макросы, поэтому он#included реализовал файлы фейспалм). - Ожидал: разработчики знают, что это такое, и почти не замечают их; напротив, отсутствие в заголовочном файле include guards будит нас и добавляет к глобальному счетчику wtf/line.
Я пользуюсь возможностью, чтобы выделить комментарий от StoryTeller:
I'd go a step further and add a descriptive
#errordirective if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.
Что будет переведено на:
#ifndef MYCLASS_TPP
#define MYCLASS_TPP
#ifndef MYCLASS_HPP
#error __FILE__ should only be included from myclass.hpp.
#endif // MYCLASS_HPP
template<typename T>
T MyClass<T>::foo(T obj)
{
return obj;
}
#endif // MYCLASS_TPP
Примечание: если блок трансляции сначала #include <myclass.hpp>, а потом #include <myclass.tpp>, то ошибки не вылетает и все нормально.
Хороший! Хотя, если я предотвратил включение файла .tpp напрямую, выдав эту ошибку, не будет ли определение MYCLASS_TPP избыточным?
@dave Нет. Если ваш пользователь сначала включает myclass.hpp, а затем myclass.tpp, ошибка не сработает.
Я не согласен с предложением включать охрану никогда не нужно. Предположим, что заголовок A.hpp должен включать другой заголовок B.hpp (поскольку, например, он использует определения, найденные в B.hpp), и предположим, что вы пишете код, который требует и A.hpp, и B.hpp. Если вы не проверите код A.hpp, вы не узнаете, что #include "B.hpp" не нужен. Затем вы должны включить как A.hpp, так и B.hpp, что приведет к двойному включению B.hpp. Защита включения предотвращает это.
@francesco Всегда есть обходной путь, но это плохой способ, которым никто не должен пользоваться: включать охрану не нужно: просто ужасно полезно.
@francesco Необычный ответ будет таким: «#pragma once также может сделать это практически в любом компиляторе».
@MaxLanghof Эта городская легенда, в которой есть охранники, безопаснее, чем pragma once, должна быть уничтожена раз и навсегда. Все аргументы, которые применяются против pragma once, относятся к включению защиты. В конце концов, я предпочитаю, чтобы системный процесс обеспечивала машина, а не человек.
@Oliv #pragma once, хотя в принципе поддерживается всеми компиляторами, тем не менее имеет поведение, определяемое реализацией и работает не во всех настройках сборки. (Если это работает для вас, это нормально, но это только ваши личные предпочтения. Кроме того, я даже не уверен в том, что это определяется реализацией, потому что это требует документирования поведения.)
@ArneVogel На этой странице MSVC рекомендуется pragma once * Он не является частью стандарта C++, но реализуется с возможностью переноса несколькими распространенными компиляторами. * ссылка на сайт Для Gcc ссылка на сайт. Для Clang см. Gcc (у clang до сих пор нет собственной полной документации!). Согласно википедия, только Cray еще ни разу не реализовал прагму. Если один целевой Cray, код, безусловно, не будет переносимым вообще.
Просто используйте pragma once во всех файлах заголовков. Компилятор гарантирует, что ваш файл будет включен только один раз. Компилятор может не распознать только в очень необоснованном состоянии: кто-то структурирует включаемые каталоги с помощью жесткой ссылки. Кто это делает? Если кто-то не может найти уникальное имя для своего файла, зачем ему лучше находить уникальное имя для каждой защиты включения для всех заголовочных файлов?
С другой стороны, защита включения может быть нарушена, потому что имя макроса не будет таким уникальным из-за копирования/вставки или файла заголовка, созданного путем первого копирования другого и т. д.
Как выбираются уникальное имя макроса: <project name>_<filename>? Как она может быть более уникальной, чем уникальность, основанная на всей структуре корневого каталога?
Итак, в конце концов, при выборе между include guard или pragma once следует учитывать стоимость работы, которая необходима для обеспечения уникальности:
1 - Для pragma once вам нужно только убедиться, что структура каталога вашей системы не перепутана благодаря жестким ссылкам.
2 - Для включить охрану для каждого файла в вашей системе вы должны убедиться, что имя макроса уникально.
Я имею в виду, что как менеджер, оценивая стоимость этой работы и риск неудачи, я допускаю только один вариант. Включить защиту используется только тогда, когда оценка не выполняется: это не решение.
Я согласен: если вы контролируете свою среду сборки (например, это частный проект), нет причин не использовать #pragma once. Если вы пишете библиотеку с открытым исходным кодом, которую хотите использовать в неясных средах сборки (встроенных, старых системах и т. д.), возможно, просто включите защиту.
@YSC Не писать, а поддерживать старую библиотеку. Для новой библиотеки, которую можно добавить в старую систему, вы просто указываете, что эта библиотека не должна быть жестко связана, и все. Нет никаких причин заставлять всех платить за древнюю практику, которая все еще может использоваться многими людьми, которых можно сосчитать с одной стороны. Это все равно, что просить миллионы программистов потратить свое время на то, чтобы невероятно повысить производительность 2-х или 3-х системных администраторов.
Я думал о компиляторах, слишком старых/непонятных, чтобы знать #pragma once ;) Но да.
Я считаю, что они оба имеют свое применение. Несколько лет назад не все компиляторы поддерживали #pragma once, поэтому многие были вынуждены использовать защиту заголовков, однако сегодня большинство компиляторов должны без проблем полностью поддерживать #pragma once. Обычно, если у меня есть один заголовочный файл, который является объявлением класса, я буду использовать защиту заголовков с именем файла класса, где этот файл класса является именем класса. Если у меня есть заголовочный файл с кучей макросов, определений, констант и просто автономных объявлений функций, то я, скорее всего, буду использовать #pragma once. Это просто мое предпочтение.
Они должны присутствовать во всех заголовочных файлах, которые не предполагается встраивать несколько раз. Если предполагается, что
myclass.tppбудет включен только вmyclass.hpp, то имеет смысл добавить дополнительные охранники.