Hallo da drau\u00dfen,<\/p>\n
heute mal wieder etwas C++-Sachen.<\/p>\n
In der Regel inkludiert man in C++-Klassen, speziell wenn es um Qt geht, verschiedene andere Klassen, seien es jetzt QString’s, QList-Elemente oder eben selbst definierte Klassen, die verschiedene Business-Logik kapseln. Diese packt man dann manchmal auch in member-Variablen oder nutzt diese in privaten oder public-Methoden als \u00dcbergabe-Parameter.<\/p>\n
Prinzipiell gibt es zwei Methoden, um Klassen einzubinden:<\/p>\n
F\u00fcr Neulinge erkl\u00e4re ich mal die beiden Dinge:<\/p>\n
Hier mal ein Beispiel-Code f\u00fcr ein Klassen-Header, die einen Methode hat, der ein QString \u00fcbergeben wird. Die Datei speichere ich mal unter testklasse.h ab.<\/p>\n
\r\n#ifndef TESTKLASSE_H\r\n#define TESTKLASSE_H\r\n#include \r\n#include \r\n\r\nclass TestKlasse : public QObject {\r\npublic:\r\n TestKlasse(); \/\/Konstruktor der Klasse\r\n QString getHelloWorld() const;\r\n}\r\n#endif \/\/ TESTKLASSE_H\r\n<\/pre>\nNormalerweise generiert Qt die meisten Sachen selbst. Trotzdem kurze Erkl\u00e4rung:<\/p>\n
Die erste Zeile wird dazu genutzt, um h-Dateien nicht mehrfach zu laden. Wird eine h-Datei inkludiert, wird gepr\u00fcft, ob das „Makro“ TESTKLASSE_H schon einmal definiert (also geladen) wurde. Ist dies nicht der Fall, wird dieses „Makro“ definiert (2.Zeile).
\nIn der dritten und vierten Zeile werden die entsprechenden referenzierten \/ genutzten Klassen, n\u00e4mlich QObject und QString geladen<\/p>\n
Dann wird die Klasse definiert als Unterklasse von QObject und Konstruktor und eine Methode getHelloWorld() definiert.<\/p>\n
Die letzte Zeile definiert dann das Ende des Makros (Laden der TestKlasse).<\/p>\n
Soweit, sogut. Durch die „#include“-Anweisungen haben wir entsprechend die genutzten Klassen direkt im H-File geladen. Die Klassendefinition steht nun sowohl im h-File als auch im zugeh\u00f6rigen cpp-File (also der Implementierung) zur Verf\u00fcgung.<\/p>\n
Nun noch die zugeh\u00f6rige Cpp-Datei (testklasse.cpp)<\/p>\n
\r\n#include \"testklasse.h\"\r\n\/\/Definition des Konstruktors\r\nTestKlasse::TestKlasse() : public QObject() {\r\n\r\n}\r\n\r\nQString TestKlasse::getHelloWorld() {\r\n return QString(\"Hello World!\");\r\n}\r\n<\/pre>\nWie man sieht, ben\u00f6tigt man hier keinen Include von QString und QObject mehr.<\/p>\n
Forward-Deklaration der Klasse<\/h4>\n
Prinzipiell kann man die includes aber auch in die Implementierung verlagern. Dazu mal wieder unsere modifzierte h-Datei testklasse.h:<\/p>\n
\r\n#ifndef TESTKLASSE_H\r\n#define TESTKLASSE_H\r\n\r\nclass QString;\r\nclass QObject;\r\n\r\nclass TestKlasse : public QObject {\r\npublic:\r\n TestKlasse(); \/\/Konstruktor der Klasse\r\n QString getHelloWorld() const;\r\n}\r\n#endif \/\/ TESTKLASSE_H\r\n<\/pre>\nHier f\u00e4llt auf, dass nun keinerlei Includes in der Datei vorhanden sind. Daf\u00fcr werden die Klassen QString und QObject in Zeile 4 und 5 Forward-Deklariert. Die Forward-Deklaration reserviert quasi den Namen der Klasse, die „Implementierung“ erfolgt dann in der cpp-Klasse. Das hei\u00dft, in der cpp-Klasse m\u00fcssen dann die eigentlichen Includes gemacht werden.<\/p>\n
Somit sieht unsere testklasse.cpp folgenderma\u00dfen aus:<\/p>\n
\r\n#include \"testklasse.h\"\r\n#include \r\n#include \r\n\/\/Definition des Konstruktors\r\nTestKlasse::TestKlasse() : public QObject() {\r\n\r\n}\r\n\r\nQString TestKlasse::getHelloWorld() {\r\n return QString(\"Hello World!\");\r\n}\r\n<\/pre>\nDer Unterschied zum ersten Fall (include in h-Datei) ist, dass die includes in Zeile 2 und 3 nun im cpp-File zwingend definiert sein m\u00fcssen.<\/p>\n
Selbstverst\u00e4ndlich kann man die Dinge auch mischen, d.h. bestimmte Klassen \u00fcbers h-File laden und andere Klassen \u00fcber Forward-Deklaration laden.<\/p>\n
Da ich prim\u00e4r aus dem Java-Bereich komme und mir C++ sp\u00e4ter erst selbst angeeignet habe, war f\u00fcr mich die erste Methode immer die Wahl, auch wenn das nicht immer zu 100% funktioniert hat. Speziell, wenn man Kreuzabh\u00e4ngigkeiten zwischen Klassen besitzt, z.B. Klasse A beinhaltet eine Liste von Klasse B, die wiederum einen R\u00fcck-Verweis (als Pointer) auf die Klasse A besitzt. Wenn beide jeweils in der h-Datei auf das jeweilig andere verweisen, kommt ein gro\u00dfes Kuddelmuddel heraus und der C++-Compiler steigt aus.
\nIn solchen F\u00e4llen [b]MUSS[\/b] man eine Forward-Deklaration benutzen.<\/p>\n
Wann nutzt man also nun welche Methode?<\/h4>\n
Vorteil der ersten Variante ist die klar definierte Struktur. Durch Anschauen der h-Datei bekommt man sofort einen \u00dcberblick, welche weiteren h\/cpp-Dateien entsprechend genutzt werden. Speziell zur Erzeugung von Klassenb\u00e4umen ist das nett.
\nGro\u00dfer Nachteil ist, dass bei irgendeiner \u00c4nderung der h-Datei automatisch auch alle abh\u00e4ngigen Klassen mit \u00fcbersetzt werden (inkl. h-Dateien). Das f\u00fchrt im schlimmsten Fall dazu, dass bei \u00c4nderung einer h-Datei das gesamte Projekt neu \u00fcbersetzt werden muss, wenn denn z.B. die h-Datei eine essentielle, \u00fcberall genutzte Datei ist. Bei gr\u00f6\u00dferen Projekten geht so ziemlich viel Compile-Zeit verloren.<\/p>\n
Das ist wiederum der Vorteil der zweiten Variante. Dort werden nur die Klassen, die direkt die ge\u00e4nderte Klasse (mit dem ge\u00e4nderten h-File) nutzen \u00fcbersetzt, die h-Datei bleibt entsprechend unanger\u00fchrt. Klassen, wiederum auf diese h-Datei verweisen m\u00fcssen dann nicht mehr \u00fcbersetzt werden.
\nHier spart man sich wirklich viel Compile-Zeit.
\nEin weiterer Vorteil ist, dass man z.B. unterschiedliche Implementierungen vornehmen kann, je nach Qt-Version, Makros.<\/p>\n
Ich pers\u00f6nlich nutze aktuell eine Misch-Variante. Da sich Qt-Klassen i.d.R. nicht \u00e4ndern, inkludiere ich diese \u00fcber die erste Methode, also direkt im h-File und nutze die Forward-Deklaration f\u00fcr meine eigenen Klassen.
\nDas spart dann Compile-Zeit und zumindest, was an Qt-Klassen inkludiert wird, kann ich direkt aus dem h-File ersehen.<\/p>\n","protected":false},"excerpt":{"rendered":"
Hallo da drau\u00dfen, heute mal wieder etwas C++-Sachen. In der Regel inkludiert man in C++-Klassen, speziell wenn es um Qt geht, verschiedene andere Klassen, seien es jetzt QString’s, QList-Elemente oder eben selbst definierte Klassen, die verschiedene Business-Logik kapseln. Diese packt man dann manchmal auch in member-Variablen oder nutzt diese in privaten oder public-Methoden als \u00dcbergabe-Parameter. […]<\/p>\n","protected":false},"author":1,"featured_media":218,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,6],"tags":[],"_links":{"self":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/210"}],"collection":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/comments?post=210"}],"version-history":[{"count":10,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/210\/revisions"}],"predecessor-version":[{"id":223,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/210\/revisions\/223"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/media\/218"}],"wp:attachment":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/media?parent=210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/categories?post=210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/tags?post=210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}