Wohin mit Membern

DrGreenthumb

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

Dobi

Wie gehts denn noch weiter unten als bei A?

314159265358979

DrGreenthumb schrieb:

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

cooky hat das Beispiel falsch gemacht, die Member gehören natürlich ganz nach unten. Darf man dich dann also zu A zuordnen?

DrGreenthumb

314159265358979 schrieb:

DrGreenthumb schrieb:

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

cooky hat das Beispiel falsch gemacht, die Member gehören natürlich ganz nach unten. Darf man dich dann also zu A zuordnen?

weiß nicht, ich mache die Regeln nicht Mich hat bei A auch gestört das erst die Member, dann die Methoden kommen und außerdem das struct statt class.

314159265358979

Ob struct oder class ist doch grundsätzlich egal, darum gehts auch gar nicht.

Dobi

Bei class rutschen die privaten Member dadurch, dass oben ja irgendwo public steht, noch was weiter nach unten.

DrGreenthumb

314159265358979 schrieb:

Ob struct oder class ist doch grundsätzlich egal, darum gehts auch gar nicht.

die beiden Beispiele machen mir zu sehr Gebrauch von der Default-Visibility bei struct vs. class. Aber OK, zähl mich zu A

hustbaer

314159265358979 schrieb:

DrGreenthumb schrieb:

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

cooky hat das Beispiel falsch gemacht, die Member gehören natürlich ganz nach unten. Darf man dich dann also zu A zuordnen?

Meinst du so?

class Foo
{
public:
    Foo();
    void Fun();

protected:
    Foo(int, int);
    void LessFun();

private:
    int m_memba;
};

So mach ich es auf jeden Fall...

Dobi

Jo, genauso siehts bei mir auch aus.

314159265358979

@hustbaer: Ja, genau.

GorbGorb

hustbaer schrieb:

class Foo
{
public:
    Foo();
    void Fun();

protected:
    Foo(int, int);
    void LessFun();

private:
    int m_memba;
};

So macht es meines Wissens nach auch boost.

hustbaer

Also bei Boost ist mir hauptsächlich aufgefallen, dass es kaum Sachen gibt, die in den zig verschiedenen Libs so richtig konsequent überall gleich gemacht würden.

Ist aber auf jeden Fall der "Stil" den ich in "Fremdcode" am häufigsten gesehen habe.

otze

Ich Atme B.

Member haben für mich beim Codeverständnis die größte Bedeutung und bei allen leuten die A schreiben fluche ich, dass ich immer so lange scrollen muss, um irgendwas zu finden...

asc

Mir ist eigentlich vollkommen egal ob a oder b, wobei ich eher zu a tendiere. Mir ist die Schnittstelle in der Regel wesentlich wichtiger.

Ich ziehe ohnehin kurze Klassen den langen vor, so das ich die Scrollorgien die otze anspricht, auch nicht so schwer wiegen wenn man den wirklich die Implementierungsdetails benötigt (zudem sehe ich es nicht so, das Member für das Codeverständnis wichtiger sind als die Schnittstelle).

wer B bevorzugt ist definitiv ein schlechter Programmierer

Swordfish

DrGreenthumb schrieb:

[...] Schlimm genug dass das überhaupt mit in den Header muss.

Gut, in irgendeinen Header muss es, aber was ist mit pImpl?

Private Member ganz oben.

Wenn ich mir eine Implementierung anschaue, interessiere ich mich mehr für die Details als für die Schnittstelle. Die sollte abstrahiert in einer Basisklasse oder einem Interface vorliegen.

hustbaer

µ schrieb:

..die Schnittstelle. Die sollte abstrahiert in einer Basisklasse oder einem Interface vorliegen.

Es geht hier um C++

hustbaer schrieb:

µ schrieb:

..die Schnittstelle. Die sollte abstrahiert in einer Basisklasse oder einem Interface vorliegen.

Es geht hier um C++

Dann ersetze "Interface" durch "Abstrake Basisklasse"

Abstrakte Basisklassen meidet man in C++: machen alles langsam wegen virtual