Unklares Klassenkonstrukt im Qt-Creator

Verschiedenes zu Qt
Antworten
guenni81
Beiträge: 134
Registriert: 29. Juli 2006 02:22

Unklares Klassenkonstrukt im Qt-Creator

Beitrag von guenni81 »

Hallo zusammen,
beim durchstöbern des Qt Creator fällt mir immer wieder ein ähnliches Klassenkonstrukt wie das folgende auf:

Code: Alles auswählen

class CTestPrivate;
class CTest
{
private:
    CTestPrivate * const d;
};

class CTestPrivate
{
    public:
        int irgendwas;
};
 
CTest::CTest() : d(new CTestPrivate)
{
}
 
CTest::~CTest()
{
    delete d;
}
Leider ist mir nicht ganz klar was damit bezweckt wird, kann mir dies eventuell jemand erklären?
mfg
Günni
franzf
Beiträge: 3114
Registriert: 31. Mai 2006 11:15

Re: Unklares Klassenkonstrukt im Qt-Creator

Beitrag von franzf »

guenni81 hat geschrieben: Leider ist mir nicht ganz klar was damit bezweckt wird, kann mir dies eventuell jemand erklären?
Such mal nach PIMPL.
Der große Vorteil ist Binarkompatibilität.
Probleme entstehen, wenn du einer Klassen neue Membervariablen hinzufügst. Dabei ändert sich die ABI, und alle Programme die die Klasse nutzen müssen neu gebaut werden.
Wenn du die privaten Member in ne eigene private Klasse auslagerst, kannst du belibig Member inzufügen oder entfernen, ohne dass du die eigntliche Klasse veränderst (bei dir "CTest").
guenni81
Beiträge: 134
Registriert: 29. Juli 2006 02:22

Beitrag von guenni81 »

Hallo franzf,
mit dem Stichwort PIMPL bin ich doch schon mal ein stückchen weitergekommen. Soweit ich das verstanden habe handelt es sich hierbei um eine vorgehensweise um Abhänigkeiten zu anderen Programmen oder Modulen zu reduzieren um Binarkompatibilität zu erreichen.
Mit dem Stichwort Binarkompatibilität tue ich mir im moment noch ein wenig schwer, vielleicht kannst du mir da nochmals ein wenig weiterhelfen.

Nehmen wir mal an ich würde eine DLL Datei erzeugen die von anderen Entwicklern genutzt wird, so müssten diese Ihre Programme jedesmal neu kompilieren sobald ich der Klasse CTest einen neuen privaten Member hinzufüge oder entferne um mit der neuen Version kompatibel zu sein. Wenn ich dies nun recht verstehe, wird dies mit hilfe des PIMPL versucht zu vermeiden, in dem man alle Privaten Member in eine seperate Klasse schreibt und somit das Ursprüngliche Interface das genutzt wird nicht verändert wird. Hab ich das soweit richtig verstanden oder bin ich da jetzt irgendwie voll auf dem Holzweg?

Da hätte ich noch ne Frage zur ABI, ändert die sich nur beim Hinzufügen von neuen Variablen oder auch Funktionen?
mfg
Günni
franzf
Beiträge: 3114
Registriert: 31. Mai 2006 11:15

Beitrag von franzf »

guenni81 hat geschrieben:Mit dem Stichwort Binarkompatibilität tue ich mir im moment noch ein wenig schwer, vielleicht kannst du mir da nochmals ein wenig weiterhelfen.
Ich nicht (bin zu faul :P)
http://de.wikipedia.org/wiki/Bin%C3%A4rschnittstelle
http://de.wikipedia.org/wiki/Bin%C3%A4r ... lit%C3%A4t
Hab ich das soweit richtig verstanden oder bin ich da jetzt irgendwie voll auf dem Holzweg?
Genau so ist es.
Da hätte ich noch ne Frage zur ABI, ändert die sich nur beim Hinzufügen von neuen Variablen oder auch Funktionen?
Funktionen hinzufügen ist kein Problem. Bei virtuellen Funktionen musst du aufpassen! Es darf die Reihenfolge nicht geändert werden (->vtable) Du darfst aber sehrwohl neue virtuelle Funktionen hintenanhängen.

Auch inline-Funktionen können Probleme verursachen.
Aber lies selber :P
z.B.:
http://techbase.kde.org/Policies/Binary ... th_C%2B%2B
guenni81
Beiträge: 134
Registriert: 29. Juli 2006 02:22

Beitrag von guenni81 »

Aus den Einträgen aus Wikipedia hatte ich das irgendwie noch nicht so ganz gerafft, aber wenn mein oben genannten Beispiel ja soweit korrekt ist, dann versteh ich das ganze.
Der letzte Link sieht sehr interessant zu dem Thema aus. Siehste, dann hab ich doch mal wieder was interessantes zum programmieren dazugelernt. ;)
mfg
Günni
Antworten