Я видел, что в C ++ есть несколько различных парадигм, касающихся того, что входит в заголовочный файл и что в файл cpp. AFAIK, большинство людей, особенно те из C, делают:
foo.h
class foo {
private:
int mem;
int bar();
public:
foo();
foo(const foo&);
foo& operator=(foo);
~foo();
}foo.cpp
#include foo.h
foo::bar() { return mem; }
foo::foo() { mem = 42; }
foo::foo(const foo& f) { mem = f.mem; }
foo::operator=(foo f) { mem = f.mem; }
foo::~foo() {}
int main(int argc, char *argv[]) { foo f; }Тем не менее, мои преподаватели обычно преподают C ++ начинающим, как это:
foo.h
class foo {
private:
int mem;
int bar() { return mem; }
public:
foo() { mem = 42; }
foo(const foo& f) { mem = f.mem; }
foo& operator=(foo f) { mem = f.mem; }
~foo() {}
}foo.cpp
#include foo.h
int main(int argc, char* argv[]) { foo f; }
// other global helper functions, DLL exports, and whatnotПервоначально пришедший из Java, я также всегда придерживался этого второго способа по нескольким причинам, таким как то, что мне нужно что-то менять только в одном месте, если меняются имена интерфейса или метода, что мне нравятся разные отступы в классах, когда я посмотрите на их реализацию, и что я считаю имена более читабельными по fooсравнению с foo::foo.
Я хочу собрать "за" и "против" в любом случае. Может быть, есть еще другие способы?
Одним из недостатков моего пути, конечно же, является необходимость периодических предварительных заявлений.
foo.cppтеперь не имеет ничего общего с вашимfooклассом и должен быть оставлен пустым (возможно, но,#includeчтобы сделать вашу систему сборки счастливой).