«Using namespace» в заголовках C ++

На всех наших курсах по C ++ все учителя всегда ставят using namespace std;сразу после #includes в своих .hфайлах. Мне это кажется опасным, поскольку с тех пор, включив этот заголовок в другую программу, я получу пространство имен, импортированное в мою программу, возможно, не осознавая, не намереваясь или не желая этого (включение заголовка может быть очень глубоко вложенным).

Итак, мой вопрос двоякий: я прав, что using namespaceне следует использовать в файлах заголовков, и / или есть какой-то способ отменить это, например:

//header.h
using namespace std {
.
.
.
}

Еще один вопрос в том же духе: должен ли файл заголовка #includeвсе заголовки, которые .cppнужны соответствующему файлу, только те, которые необходимы для определений заголовков, и позволить .cppфайлу #includeостальное или ничего и объявить все, что ему нужно, как extern?
Причина вопроса такая же, как и выше: я не хочу сюрпризов при включении .hфайлов.

Кроме того, если я прав, это распространенная ошибка? Я имею в виду программирование в реальном мире и «настоящие» проекты.

Спасибо.

Вам определенно НЕ следует использовать using namespaceв заголовках именно по той причине, по которой вы говорите, что это может неожиданно изменить значение кода в любых других файлах, которые включают этот заголовок. Невозможно отменить действие, using namespaceчто является еще одной причиной его опасности. Я обычно просто использую grepили что-то подобное, чтобы убедиться, что using namespaceон не вызывается в заголовках, вместо того, чтобы пытаться что-то более сложное. Вероятно, это тоже отмечают средства проверки статического кода.

Заголовок должен включать только те заголовки, которые ему необходимы для компиляции. Простой способ обеспечить это - всегда включать собственный заголовок каждого исходного файла в первую очередь перед любыми другими заголовками. Тогда исходный файл не скомпилируется, если заголовок не является самодостаточным. В некоторых случаях, например при обращении к классам деталей реализации в библиотеке, вы можете использовать форвардные объявления вместо того, #includeчтобы иметь полный контроль над определением такого прямого объявленного класса.

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

Пункт 59 в книге Саттера и Александреску «Стандарты программирования C ++: 101 правила, рекомендации и передовой опыт» :

59. Не записывайте использование пространств имен в заголовочный файл или перед #include.

Пространства имен usingпредназначены для вашего удобства, а не для того, чтобы вы навязывали их другим: никогда не пишите usingдекларацию или usingдирективу перед #includeдирективой.

Следствие: в файлах заголовков не записывайте usingдирективы или usingобъявления на уровне пространства имен ; вместо этого явно уточняйте все имена по пространству имен.

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

using Декларация приносит приятель. using Директива приносит во всех приятелях в пространстве имен. Ваши учителя using namespace std;используют директиву using.

А если серьезно, у нас есть пространства имен, чтобы избежать конфликта имен. Заголовочный файл предназначен для предоставления интерфейса. Большинство заголовков не зависит от того, какой код может их включать сейчас или в будущем. Добавление usingоператоров для внутреннего удобства в заголовок навязывает эти удобные имена всем потенциальным клиентам этого заголовка. Это может привести к конфликту имен. И это просто грубо.

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

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

Что касается пространств имен, я обычно использую явную область видимости пространства имен в своих файлах заголовков и помещаю только using namespaceв свои файлы cpp.

Ознакомьтесь со стандартами кодирования Goddard Space Flight Center (для C и C ++). Это оказалось немного сложнее, чем раньше - см. Обновленные ответы на вопросы SO:

• Стоит ли использовать #include в заголовках
• Самодостаточные заголовки в C и C ++

Стандарт кодирования GSFC C ++ гласит:

§3.3.7 Каждый файл заголовка должен содержать #includeфайлы, необходимые для компиляции, а не заставлять пользователей обращаться к #includeнужным файлам. #includesдолжен быть ограничен тем, что нужно заголовку; другое #includesследует поместить в исходный файл.

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

Вы правы, что using namespaceв шапке опасно. Я не знаю, как это исправить. Обнаружить это несложно, однако достаточно выполнить поиск using namespaceв файлах заголовков. По этой последней причине это нечасто в реальных проектах. Более опытные коллеги скоро будут жаловаться, если кто-то сделает что-то подобное.

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

Ты прав. И любой файл должен включать только заголовки, необходимые для этого файла. Что касается "делать что-то неправильно в реальных проектах?" - о да!

Как и все в программировании, прагматизм должен победить догматизм, ИМО.

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

С другой стороны, если бы это было решение одного разработчика в одном (не закрытом) заголовочном файле, я могу видеть, как это могло бы вызвать путаницу в команде, и этого следует избегать.

Что касается вопроса «Есть ли способ отменить [ usingобъявление]?»

Думаю, полезно отметить, что на usingобъявления влияет область видимости.

#include <vector>

{   // begin a new scope with {
    using namespace std;
    vector myVector;  // std::vector is used
}   // end the scope with }

vector myOtherVector;   // error vector undefined
std::vector mySTDVector // no error std::vector is fully qualified

Так что да. Ограничивая область действия usingобъявления, ее действие длится только в пределах этой области; он «отменяется», когда этот объем заканчивается.

Когда usingобъявление объявляется в файле за пределами любой другой области, оно имеет файловую область и влияет на все в этом файле.

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

Я считаю, что вы можете безопасно использовать 'using' в заголовках C ++, если вы пишете свои объявления во вложенном пространстве имен следующим образом:

namespace DECLARATIONS_WITH_NAMESPACES_USED_INCLUDED
{
    /*using statements*/

    namespace DECLARATIONS_WITH_NO_NAMESPACES_USED_INCLUDED
    {
        /*declarations*/
    }
}

using namespace DECLARATIONS_WITH_NAMESPACES_USED_INCLUDED::DECLARATIONS_WITH_NO_NAMESPACES_USED_INCLUDED;

Это должно включать только то, что объявлено в 'DECLARATIONS_WITH_NO_NAMESPACES_USED_INCLUDED' без используемых пространств имен. Я тестировал его на компиляторе mingw64.