C++ Schreib-still
-
Da du diese Frage stellst sind bei dir Getter und Setter sicher sowas wie im folgenden Beispiel oder?
class Sample { int attribute; int getAttribute() const { return attribute; } void setAttribute( int attrib ) { attribute = attrib; } };Sowas mache ich inline, also direkt in der Klassendefinition. Ansonsten finde ich die Worte Getter und Setter ungeeignet da sie irreführend sind. Man möchte das Modell das eine Klasse modelliert manipulieren und nicht die Implementierung. Daher gibt es bei mir nur drei Kategorien: public interface, protected interface und private interface.
Implementierungsdetails versuche ich so weit wie möglich zu kapseln, das heißt im Idealfall muss ich nur ein paar private Methoden ändern. Man sollte allerdings nicht vergessen, dass die Implementierung für den Anwender durchaus wichtig sein kann was Laufzeitverhalten angeht, zum Debuggen ist es schön den Quellcode zu haben, etc.
-
Vorschlag:
Erst die public-Sachen, dann private... Den Benutzer kann ja nur das public interessieren
-
Aquae schrieb:
Erst die public-Sachen, dann private... Den Benutzer kann ja nur das public interessieren
Interessant, ich mache immer privat zuerst weil den Leser des Source Codes kann ja nur die interna interessieren - das public interface steht ja in der doku

-
Shade Of Mine schrieb:
Aquae schrieb:
Erst die public-Sachen, dann private... Den Benutzer kann ja nur das public interessieren
Interessant, ich mache immer privat zuerst weil den Leser des Source Codes kann ja nur die interna interessieren - das public interface steht ja in der doku

Interessant, bei mir steht private am Schluss, weil das interessiert garantiert niemanden, denn da steht nur ein KlassePrivate d;*

Kommentare ala "Konstruktoren", "Destruktor", "Public Methoden" lass ich weg. Denn mit der Dokumentation der Methoden gehen diese Kommentare eh unter/machen den Header nicht übersichtlicher

Wichtiger ist mir da eher eine gewisse Konsistenz im Interface (Methodenbenennungen, Klammersetzung im Source, Einrückung (Tab vs Leerzeichen) usw)
-
Shade Of Mine schrieb:
Aquae schrieb:
Erst die public-Sachen, dann private... Den Benutzer kann ja nur das public interessieren
Interessant, ich mache immer privat zuerst weil den Leser des Source Codes kann ja nur die interna interessieren - das public interface steht ja in der doku

Das sehen viele OS-Entwickler (leider) anders. Da ist das public Interface die Doku.

-
Tachyon schrieb:
Shade Of Mine schrieb:
Aquae schrieb:
Erst die public-Sachen, dann private... Den Benutzer kann ja nur das public interessieren
Interessant, ich mache immer privat zuerst weil den Leser des Source Codes kann ja nur die interna interessieren - das public interface steht ja in der doku

Das sehen viele OS-Entwickler (leider) anders. Da ist das public Interface die Doku.

Stimmt, das kann ich auch nicht verstehen. Und ich rede hier nicht von Projekten wo der Author den Code möglichst unzugänglich machen wollte, sondern von richtigen OSS-Projekten wie XFCE.
Was ich auch immer wieder erstaunlich finde: man findet nirgends in einem Header-File ganz oben einen Kommentar der kurz erklärt was in der Datei ist. Im Regelfall steht dort nur der Copy 'n Paste GPL Text.
Kann ich echt nicht nachvollziehen.
-
franz schrieb:
Interessant, bei mir steht private am Schluss, weil das interessiert garantiert niemanden, denn da steht nur ein KlassePrivate d;*

Ah und in KlassePrivate steht ein KlassePrivatePrivate* d; ?
-
Shade Of Mine schrieb:
franz schrieb:
Interessant, bei mir steht private am Schluss, weil das interessiert garantiert niemanden, denn da steht nur ein KlassePrivate d;*

Ah und in KlassePrivate steht ein KlassePrivatePrivate* d; ?
Ich schätze mal, er auf das Handle-Body-Idiom anspricht, und dass außer einer Forward-Deklaration nichts von
KlassePrivateim Header zu sehen ist.
-
Tachyon schrieb:
und dass außer einer Forward-Deklaration nichts von
KlassePrivateim Header zu sehen ist.Exakt. Aber Handle-Body-Idiom kannte ich noch nicht, mir ist das als "Pimpl" bekannt.
-
Tachyon schrieb:
Ich schätze mal, er auf das Handle-Body-Idiom anspricht, und dass außer einer Forward-Deklaration nichts von
KlassePrivateim Header zu sehen ist.Mir durchaus bewusst, aber das beantwortet die Frage nicht:
man hat Klassen die private Member und Funktionen haben - zB eben die Impl-Klasse.Und wie sieht es dort aus?
-
Shade Of Mine schrieb:
Tachyon schrieb:
Ich schätze mal, er auf das Handle-Body-Idiom anspricht, und dass außer einer Forward-Deklaration nichts von
KlassePrivateim Header zu sehen ist.Mir durchaus bewusst, aber das beantwortet die Frage nicht:
man hat Klassen die private Member und Funktionen haben - zB eben die Impl-Klasse.Und wie sieht es dort aus?
Das braucht einen (als Anwender) nicht zu interessieren. Das ist ja, neben der Reduzierung der Compilezeit, der Sinn der Sache.
-
Tachyon schrieb:
Shade Of Mine schrieb:
Tachyon schrieb:
Ich schätze mal, er auf das Handle-Body-Idiom anspricht, und dass außer einer Forward-Deklaration nichts von
KlassePrivateim Header zu sehen ist.Mir durchaus bewusst, aber das beantwortet die Frage nicht:
man hat Klassen die private Member und Funktionen haben - zB eben die Impl-Klasse.Und wie sieht es dort aus?
Das braucht einen (als Anwender) nicht zu interessieren. Das ist ja, neben der Reduzierung der Compilezeit, der Sinn der Sache.
Dann bist du nicht besser als die Leute bei vielen OS Projekten. Denk doch auch mal an andere Programmierer (in deinem Team).
-
Tippgeber schrieb:
Tachyon schrieb:
Shade Of Mine schrieb:
Tachyon schrieb:
Ich schätze mal, er auf das Handle-Body-Idiom anspricht, und dass außer einer Forward-Deklaration nichts von
KlassePrivateim Header zu sehen ist.Mir durchaus bewusst, aber das beantwortet die Frage nicht:
man hat Klassen die private Member und Funktionen haben - zB eben die Impl-Klasse.Und wie sieht es dort aus?
Das braucht einen (als Anwender) nicht zu interessieren. Das ist ja, neben der Reduzierung der Compilezeit, der Sinn der Sache.
Dann bist du nicht besser als die Leute bei vielen OS Projekten. Denk doch auch mal an andere Programmierer (in deinem Team).
Die sollten i.d.R. nicht fremden Code bearbeiten, sondern nur die gegebenen Interfaces benutzen. Für alles andere gibt es die Software Design Description. Da stehen auch Implementierungsdetails drin.
-
Die private-Klassen sind ja auch nicht Teil der öffentlichen Klassen, sie dienen rein als "member-container", in den ich neue Member einfügen kann, ohne dass sich an der ABI meiner lib etwas ändert.
Füge ich nur ein neues Member zu einer Klasse hinzu, muss alles neu kompiliert werden, was diese Klasse verwendet!
Neben ein paar anderen Sachen ist PIMPL das entscheidende Hilfsmittel, um Binärkompatibilität zu gewährleisten.Im Übrigen werden die private-Header eh nie mit installiert, so dass eine Verwendung nur möglich ist, wenn man sich den Header aus den sourcen holt (falls diese überhaupt zugänglich sind).
-
Ist es so schwer eine einfache Frage zu verstehen?
Es geht hier um das Layout des Codes.
Und ich will wissen wie das Layout der Impl Klasse aussieht.Ein "das hat dich als Anwender nicht zu interessieren" ist eine komplette Themenverfehlung. Genauso wie eine Erklärung des pimpl Idioms...
-
Shade Of Mine schrieb:
Ist es so schwer eine einfache Frage zu verstehen?
Es geht hier um das Layout des Codes.
Und ich will wissen wie das Layout der Impl Klasse aussieht.Ein "das hat dich als Anwender nicht zu interessieren" ist eine komplette Themenverfehlung. Genauso wie eine Erklärung des pimpl Idioms...
Ist doch klar wie diese Aussehen:
sample.hpp schrieb:
// ... SamplePrivate *d; // ...sample.cpp schrieb:
// Uncommented blob stands here
-
Shade Of Mine schrieb:
... ist eine komplette Themenverfehlung...
Nein, ist es nicht. Wir sind über die Frage "erst public oder erst private" in Bezug auf Aussagekraft der Selbstdokumentation auf PIMPL gekommen. Soll heißen, da war es, im Bezug auf die Frage des TOs, bereits leicht OT.
Solch eine Selbstdokumentation (insbesondere wenn es um public oder private geht) hat nur Sinn für den Anwender des Interfaces. Und wie bereits gesagt, braucht es den Anwender a) nicht zu interessieren, wie in Implementierung aussieht, und b) sollte es für die Implementierung eh eine ordentliche Doku geben.
-
Tachyon schrieb:
Nein, ist es nicht. Wir sind über die Frage "erst public oder erst private" in Bezug auf Aussagekraft der Selbstdokumentation auf PIMPL gekommen. Soll heißen, da war es, im Bezug auf die Frage des TOs, bereits leicht OT.
Nur pimpl war nie gefragt, es war nie das Thema.
Die Frage ist: wie ist die Klasse aufgebaut:
zuerst private, zuerst public, zuerst Methoden, was?Eine simple Frage.
Solch eine Selbstdokumentation (insbesondere wenn es um public oder private geht) hat nur Sinn für den Anwender des Interfaces.
Danach hat niemand gefragt.
Und wie bereits gesagt, braucht es den Anwender a) nicht zu interessieren, wie in Implementierung aussieht, und b) sollte es für die Implementierung eh eine ordentliche Doku geben.
Du widersprichst dir selbst (erst ist das Layout wichtig weil es ja Doku ist und dann ist es uninteressant weil es dafür Doku gibt). Aber darum geht es mir nicht.
Ich will nur wissen wie das Klassen Layout aussieht, mehr nicht.
Denn zumindest der Programmierer selber muss sich die Klasse ansehen - deshalb ist es nicht uninteressant wie sie aufgebaut ist.
-
Shade Of Mine schrieb:
...
Wenn Du es so pedantisch siehst, dann ging es auch nie darum, wie franz seine Impl-Klassen aufbaut, sondern darum, ob Stil des TOs (und nicht der von franz) gut ist.
-
hmm naja ,glaub ich hab wirklich eine große Diskussion eingeführt

Das mit setter/Getter ist wirklich etwas verwirrent vllt. verwende ich da mal andere Wörter für...
Ahja und man wollte ein bisjen Code hab ich gelesen^^
Hier mal eine TemplateKlasse die ich zur Übung geschrieben habe...// DAT.hpp #ifndef DAT_HPP_ #define DAT_HPP_ template <class DATA> class DAT { private: DATA Var; public: DATA getData() const; bool isEmpty(); void setData(DATA Wert); }; //----------> Getter! <----------// template <class DATA> DATA DAT<DATA>::getData() const { return Var; } //----------> Prüfer! <----------// template <class DATA> bool DAT<DATA>::isEmpty() { if (Var == 0) {return true;} else {return false;} } //----------> Setter! <----------// template <class DATA> void DAT<DATA>::setData(DATA Wert) { Var = Wert; } //----------> TheEnd! <----------// #endifMüsste eigentlich reichen...
Mfg Wikinger75!