Widziałem, że w C ++ istnieje kilka różnych paradygmatów dotyczących tego, co wchodzi do pliku nagłówkowego, a co do pliku CPP. AFAIK, większość ludzi, szczególnie tych z pochodzenia C, wykonuje:
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; }
Jednak moi wykładowcy zwykle uczą języka C ++ dla początkujących:
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
Pochodzę z Javy i zawsze trzymałem się tej drugiej drogi z kilku powodów, takich jak to, że muszę coś zmienić tylko w jednym miejscu, jeśli zmieni się nazwa interfejsu lub metody, że podoba mi się różne wcięcie rzeczy w klasach, gdy spójrz na ich implementację i że uważam, że nazwy są bardziej czytelne w foo
porównaniu do foo::foo
.
Chcę zbierać argumenty za i przeciw dla obu stron. Może są jeszcze inne sposoby?
Wadą mojego sposobu jest oczywiście potrzeba okazjonalnych deklaracji forward.
foo.cpp
teraz nie ma nic wspólnego z twojąfoo
klasą i powinno pozostać puste (być może po#include
to, aby twój system budowania był szczęśliwy).