C++ Schreib-still

[Shade Of Mine]

Tachyon schrieb:

Ich schätze mal, er auf das Handle-Body-Idiom anspricht, und dass außer einer Forward-Deklaration nichts von KlassePrivate im 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?

[Tachyon]

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 KlassePrivate im 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.

[Tippgeber]

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 KlassePrivate im 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).

[Tachyon]

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 KlassePrivate im 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.

[franz]

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).

[Shade Of Mine]

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...

[franz-versteher]

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

[Tachyon]

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.

[Shade Of Mine]

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.

[Tachyon]

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.

[Wikinger75]

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! <----------//

#endif

Müsste eigentlich reichen...

Mfg Wikinger75!

[Shade Of Mine]

Tachyon schrieb:

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.

Wie langweilig...

Aber gut, war nicht anders zu erwarten.

Darf ich dennoch eine Antwort auf meine simple Frage bekommen oder ist das auch zu OT? Oder ist die antwort zu uninteressant, oder magst du mir das Bridge Pattern erklären?

[Tippgeber]

Wikinger75 schrieb:

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! <----------//

#endif

Müsste eigentlich reichen...

Mfg Wikinger75!

a) Sehr unschöner Mix aus Englisch und Deutsch, sei konsistent!
b) Sehr ungewöhnlich Methoden mit kleinen Buchstaben zu beginnen und Variablen mit großen
c) MAN SCHREIBT NICHT KOMPLETT GROSS DAS IST SEHR SCHWER ZU LESEN UND DAHER NUR FÜR MAKROS SINNVOLL DAMIT MAN ES NICHT MIT IHREM EINSATZ ÜBERTREIBT
d) isEmpty darf ruhig const sein und ihre Implementierung ist grauenhaft, vereinfache sie zu "return Var == 0;
e) die Klasse ist so ziemlich sinnlos, sie scheint boost::optional imitieren zu wollen, aber nicht so wirklich konsequent damit zu sein, denn

DAT< int > i; 
i.setData( 0 );
// btw. na fällt dir was auf?

führt zu einem isEmpty() == false, dabei ist mein Objekt gar nicht leer.

[freaky]

Wenn einen Anwender das Aussehen nicht intressiert, warum ist es dann so wichtig für euch das public vor private steht ? Ich finde bevor man Variablen benutzt, indem Falle Membervariablen, sollten sie über der Funktionalität stehen, damit man vorher sieht was existiert. Außerhalb einer Klasse oder einer Struktur muss eine Variable auch vor einer Funktion deklariert oder definiert sein, wieso dieses Schema in der Klasse dann verändern?

[Wikinger75]

führt zu einem isEmpty() == false, dabei ist mein Objekt gar nicht leer.

Ja wenn dein Objekt gar nicht leer ist dan mus ja false zurückgegeben werden^^

[Tippgeber]

Wikinger75 schrieb:

führt zu einem isEmpty() == false, dabei ist mein Objekt gar nicht leer.

Ja wenn dein Objekt gar nicht leer ist dan mus ja false zurückgegeben werden^^

Gemeint war natürlich isEmpty() == true.

[Dravere]

Wikinger75 schrieb:

hmm naja ,glaub ich hab wirklich eine große Diskussion eingeführt

Ich hab es ja gesagt, die Büchse der Pandora. Man kann mit Programmierer nicht vernünftig über dieses Thema diskutieren

@Shade Of Mine,
Ach, hack doch auf diesen Armen nicht so rum.

@Arme, welche von Shade Of Mine in Stücke gehackt werden,
Shade Of Mine wollte doch nur wissen, wie die Pimpl Klasse denn nun aufgebaut ist. Was wohl ziemlich schnell zum Schluss führen wird, dass sie genau gleich wie die normalen Klassen aufgebaut sind. Deswegen empfinde ich die Bemerkung von franz ziemlich überflüssig, denn irgendwo hat er seine Funktionen und co auch nach einem Schema organisiert. Oder hat er ein riesiges Durcheinander in der Pimpl Klasse, nur weil es eine Pimpl Klasse ist? Das würde ich als ziemlich dumm empfinden

Grüssli

[freaky]

Ich persöhnlich hätte wahrscheinlich die Klasse so "designed"

// DAT.hpp
#ifndef DAT_HPP_
#define DAT_HPP_

template <class T> ///überlicherweiße nimmt man "T"
class dat
{
    private:
        T var;  ///var klein
    public:
        T getData() const;
        bool isEmpty() const; ///gibt nur etwas zurück, also const
        void setData(T); ///nur den Typ und nicht den Namen der Variable festlegen
};

//----------> Getter! <----------//
template <class T> 
T dat<T>::getData() const { return var; }

//----------> Prüfer! <----------//
template <class T>
bool dat<T>::isEmpty() const
{
     if (var == 0) { return true; }
     else { return false; } ///else ist nicht unbedingt notwendig
}

//----------> Setter! <----------//
template <class T>
void dat<T>::setData(T var) { this.var = var;} ///Klasse einsprachig lassen

//----------> TheEnd! <----------//

#endif

[Wikinger75]

this.var = var;

this ist doch ein Zeiger, müsste das den nicht so sein?

this->var = var;

[Tippgeber]

Wikinger75 schrieb:

this.var = var;

this ist doch ein Zeiger, müsste das den nicht so sein?

this->var = var;

Da hast du recht, der ist wahrscheinlich von seiner IDE verwöhnt

FreakY<3Cpp schrieb:

Ich persöhnlich hätte wahrscheinlich die Klasse so "designed"

// DAT.hpp
#ifndef DAT_HPP_
#define DAT_HPP_

template <class T> ///überlicherweiße nimmt man "T"
class dat
{
    private:
        T var;  ///var klein
    public:
        T getData() const;
        bool isEmpty() const; ///gibt nur etwas zurück, also const
        void setData(T); ///nur den Typ und nicht den Namen der Variable festlegen
};

//----------> Getter! <----------//
template <class T> 
T dat<T>::getData() const { return var; }

//----------> Prüfer! <----------//
template <class T>
bool dat<T>::isEmpty() const
{
     if (var == 0) { return true; }
     else { return false; } ///else ist nicht unbedingt notwendig
}

//----------> Setter! <----------//
template <class T>
void dat<T>::setData(T var) { this.var = var;} ///Klasse einsprachig lassen

//----------> TheEnd! <----------//

#endif

Du hast jetzt nicht wirklich das Design geändert nur ein paar syntaktische und c++-spezifische Kleinigkeiten. Fundamentale Designfehler existieren weiterhin, wie man zum Beispiel in meinem Code-Snippet weiter oben sehen kann.

Es zahlt sich aus zuerst einen Unit-Test für eine Klasse zu schreiben und dann diese zu implementieren, dann ergibt sich das öffentliche Interface auf natürliche Art und Weise.