Seite 1 von 1
Unklares Klassenkonstrukt im Qt-Creator
Verfasst: 1. Dezember 2009 16:05
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?
Re: Unklares Klassenkonstrukt im Qt-Creator
Verfasst: 1. Dezember 2009 16:16
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").
Verfasst: 2. Dezember 2009 09:29
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?
Verfasst: 2. Dezember 2009 09:39
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
)
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
z.B.:
http://techbase.kde.org/Policies/Binary ... th_C%2B%2B
Verfasst: 2. Dezember 2009 10:40
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.
