Code-Organisation

Hallo zusammen!

Kürzlich habe ich hier gefragt, wie man die Reihenfolge der Compilierung vorgeben kann.

Gestern habe ich damit begonnen, den betreffenden Code noch einmal „von unten“ neu zu schreiben und kam jetzt auf die Idee, die Klassen, die ich am Ende zusammenfügen möchte, in einer statt drei .h/.cpp-Dateien zu organisieren. Wenn das übersetzt wird, ist es automatisch in der richtigen Reihenfolge.

Da ich aber gewohnt bin, jede Klasse in einer separaten Kombination von Header- und Implementierungsdatei zu haben und die Reihenfolge des Compilierens sowie Abhängigkeiten in einem Makefile festzulegen, frage ich mich nun, ob es der „normale Arduino-Weg“ ist, einfach alle zusammengehörenden Codeteile in einer (statt mehreren) .h/.cpp-Datei zusammenzufassen. Ist es das? Kennt jemand Seiten, die sich mit dieser Frage beschäftigen?

Jeder Hinweis ist hochwillkommen!

Gruß

Gregor

Ich bin mir nicht sicher, was genau Du meinst. Ich habe den Verdacht, daß alles in den bekannten Verzeichnissen (des Projekts und der benutzten Bibliotheken/Header) und deren Unterverzeichnissen compiliert wird. In welcher Reihenfolge das passiert, ist ziemlich egal, da jedes Modul (.c/.cpp) separat compiliert wird. Erst der Linker sucht sich alle benötigten Teile (Definitionen) aus den Object-Dateien zusammen und erzeugt daraus die ausführbare bzw. hochladbare Datei (*.hex?)

Dein (verlinktes) Problem liegt in der Auflistung und Reihenfolge der Header-Dateien, aus denen sich der Compiler und Preprozessor alle Deklarationen zusammenklaubt, während ein Modul übersetzt wird. Da ein C Compiler jedes Modul separat übersetzt, müssen die #includes in jedem Modul so vollständig und richtig sortiert sein, daß alle nachfolgend benötigten Deklarationen zuvor schon gelesen wurden. Wenn man da was vergißt oder vertauscht, hilft auch ein Makefile nicht mehr weiter :frowning:

DrDiettrich:
Dein (verlinktes) Problem liegt in der Auflistung und Reihenfolge der Header-Dateien, aus denen sich der Compiler und Preprozessor alle Deklarationen zusammenklaubt...

Genau darauf hatte ich soweit ich mich erinnere ziemlich genau geachtet. Deshalb habe ich mich auch gewundert, dass es zu diesen Problemen kam. Einfach alles überall einzubinden wäre wahrscheinlich auch eine Lösung gewesen, aber das erschien mir dann doch zu „schlampig“.

Jetzt werde ich eben die Klassen, die am Ende zu dem zusammengebaut werden, was ich haben möchte, in einer .h/.cpp-Datei zusammenfassen. Ich frage mich nur, ob das halt der „Arduino-Weg“ ist, seinen Code zu organisieren und für die richtige Reihenfolge beim Bau zu sorgen.

Gruß

Gregor

Du bist da sehr wahrscheinlich über ein anderes Problem gestolpert und bist jetzt auf dem falschen Weg

Hi Gregor,

ich denke, die Zusammenfassung von verschiedenen Klassen in einer einzigen .h/.cpp-Bibliothek hängt davon ab, wie komplex diese sind und ob sie überhaupt zusammen gehören.

Beispiele:

Meine Klasse "TSudoku" aus dem "SudokuSolverUNO" ist recht groß und hat auch mit nichts anderem zu tun. Also bleibt diese alleine in einer eigenen .h/.cpp

Das selbe ist bei meiner Klasse "TChess". Ebenfalls sehr umfangreich und mit nichts anderem als mit Schach zu verwenden.

Dagegen habe ich vor längerer Zeit eine "Toolbox5" geschrieben. Diese einzelne Bibliothek beinhaltet vieles, was man eigentlich immer wieder braucht, TButtons, TTimerSec, TTimerMillis, TBlinker und noch ein paar. Solche Klassen und die dazugehörigen Methoden nutze ich häufig und in fast allen Projekten. Es wäre m.E. recht lästig, jedes Mal den eventuell recht langen #inklude-Block einzutippen (inkl. Dreckfuhler).

Unterm Strich bedeutet es zumindes für mich, dass ich vor Projekt-Beginn schaue, welche einzelnen Klassen und/oder welche Gruppen ich brauche. Danach organisiere ich es entsprechend und habe nur sehr selten Sorgen mit der Reihenfolge.

Gruß, Rudi

Die Arduino IDE unterstützt keine spezielle Organisation von Dateien. Es empfiehlt sich daher, mit möglichst wenigen Dateien auszukommen, um die Anzahl der dafür benötigten Tabs bei der Anzeige klein zu halten. Oder man nimmt einen externen Editor, der mehr Komfort bei der Verwaltung von Dateien bietet.

Danke für Eure Anmerkungen!

Wie gesagt, bin ich gewohnt, für jede Klasse und manchmal auch für jede Funktion eine eigene .h/.cpp-Datei anzulegen und auf Abhängigkeiten im Makefile zu reagieren. Mit Klassen, die Bestandteile anderer Klassen sind, hatte ich auf dem Arduino bislang offensichtlich nicht zu tun.

Wie dem auch sei, da ich meine Programmierereien versioniere, habe ich auch noch die Variante(n), die Probleme verursacht hat/haben. Wenn mal Zeit ist, gucke ich mir das nochmal genauer an und frage ggf. hier.

Gruß

Gregor