Пространство имен C ++ вокруг объявления заголовка и определения источника

Question

Пространство имен C ++ вокруг объявления заголовка и определения источника

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

Это действительно:

MyThings.h

namespace MyThings {
void DoStuff();
void DoOtherStuff();
}

MyThings.cpp

namespace MyThings {
void DoStuff() {
// Do this.
}

void DoOtherStuff() {
// Do that.
}
}

Или я должен определить это как методы класса?

MyThings.cpp

void MyThings::DoStuff() {
// Do this.
}

void MyThings::DoOtherStuff() {
// Do that.
}

Я бы предпочел не использовать using namespace MyThings;и я предпочел бы использовать мой первый пример, если он действителен, я чувствую, что он делает код более читабельным без использования MyThings:: перед каждым идентификатором метода.

2

c++coding-style declaration namespaces

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Оба действительны, так что вы можете выбрать свой стиль по вкусу.

Существует объявленное преимущество определения функции с помощью:

void MyThings::DoStuff() {
// Do this.
}

что для этого функция должна быть уже объявлена. Таким образом, ошибки как:

void MyThings::DoStuf() {
// Do this.
}

или же

void MyThings::DoStuff(int i) {
// Do this.
}

поймали при компиляции MyThings.cpp, Если вы определите

namespace MyThings {
void DoStuff(int i) {
// Do this.
}
}

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

9