Ich habe ein Problem mit einem Sketch/Header-Gebilde, das damit zusammen zu hängen scheint, dass die Headerdateien in einer bestimmten Reihenfolge compiliert werden. Zumindest bekomme ich viele nicht nachvollziehbare Fehlermeldungen nicht zu sehen, wenn die Headerdateien Dateinamen wie
10_gEncoder.h
20_gMotor.h
30_gDrive.h
haben. Allerdings meckert der Compiler dann, dass die Namen von Makros wohl nicht mit einer Ziffer beginnen dürfen. Wenn ich dann Namen wie
x1_gEncoder.h
x2_gMotor.h
x3_gDrive.h
verwende, erhalte ich wieder die Fehlermeldungen, die bei „falscher“ Compilier-Reihenfolge erscheinen.
Wer weiß Abhilfe?
Gruß
Gregor
PS: Das vollständige Sketch-Verzeichnis habe ich gepackt und hier bereitgelegt.
Nachtrag: Den Sketch habe ich dort wieder gelöscht. Der Code hat sich zwischenzeitlich sehr verändert.
alle .ino werden in alphabetischer Reihenfolge in eine .cpp zusammengefasst, die zusätzlich am Anfang Funktionsdeklarationen der in den .ino enthaltenen Funktionen erhält.
Alle .cpp sollten sich unabhängig in beliebiger Reihenfolge übersetzen lassen.
Falls es etwas ausmacht, musst du die Reihenfolge der #include Anweisungen natürlich richtig machen
Ich habe jetzt einmal damit angefangen, das Klassengeraffel wieder zusammenzustreichen und von „unten“ anzufangen. Und der nächste Abstraktionsschritt wird erst gemacht, wenn der letzte perfekt läuft.
Schwierig ist es , wenn Klassen sich gegenseitig kennen müssen.
Und wenn du Referenzen im Kreis hast.
class A {
private: int _i;
public:int getValue() {return _i;}
};
class B {
private:
A a;
C c; // Problem
public:
A* getMyA() {return &a;}
int getAvalue () {return a.getValue(); }
};
class C {
private:
A a;
B b;
};
Kann man sich zwar fragen ob das Design nicht totaler Käse ist, aber zur Not auch mit unvollständigen Klassendeklarationen arbeiten. Lösung nur wenn nötig ...
michael_x:
Schwierig ist es , wenn Klassen sich gegenseitig kennen müssen.
...
Kann man sich zwar fragen ob das Design nicht totaler Käse ist, aber zur Not auch mit unvollständigen Klassendeklarationen arbeiten. Lösung nur wenn nötig ...
In meinem Fall geht es darum, dass ich den Antrieb (das entsprechende Objekt) meines Gebastels aus zwei Motoren (-> Motoren-Klasse) zusammensetzen möchte und diese jeweils ein Rotations-Encoder-Objekt verwenden sollen. Ich habe jetzt erstmal die Klassen für Antrieb und Motoren wieder aus dem Code entfernt und beginne mit einer Encoder-Klasse. Erst wenn die perfekt funktioniert gehe ich wieder an die Klasse für die Motoren. Da ich die Klassen-Denke vollkommen verinnerlicht habe, scheint mir das das beste/sinnvollste Vorgehen zu sein.