Ich habe gesehen, dass es in C ++ verschiedene Paradigmen gibt, was in die Header-Datei und was in die CPP-Datei geht. AFAIK, die meisten Leute, besonders die mit C-Hintergrund, machen:
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; }In der Regel unterrichten meine Dozenten Anfängern wie folgt 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 whatnotUrsprünglich aus Java stammend, habe ich mich aus mehreren Gründen immer an diesen zweiten Weg gehalten, zum Beispiel, dass ich nur an einer Stelle etwas ändern muss, wenn sich die Schnittstellen- oder Methodennamen ändern, dass ich die unterschiedlichen Einrückungen von Dingen in Klassen mag, wenn ich Blick auf ihre Umsetzung, und das finde ich Namen besser lesbar als im fooVergleich zu foo::foo.
Ich möchte Vor- und Nachteile für beide Arten sammeln. Vielleicht gibt es noch andere Möglichkeiten?
Ein Nachteil meines Weges ist natürlich die Notwendigkeit gelegentlicher Vorwärtserklärungen.
foo.cppJetzt hat nichts mit deinerfooKlasse zu tun und sollte leer gelassen werden (vielleicht aber#includeum dein Build-System glücklich zu machen).