[erledigt] Reihenfolge der Compilierung vorgeben

Hallo allerseits!

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.

Geht um .ino Dateien, .cpp oder .h Dateien ?

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 :wink:

michael_x:
Geht um .ino Dateien, .cpp oder .h Dateien ?

Momentan geht es nur um eine .ino- und drei .h-Dateien.

michael_x:
Falls es etwas ausmacht, musst du die Reihenfolge der #include Anweisungen natürlich richtig machen :wink:

Ich bin mir sicher, dass diese Anweisungen in der richtigen Reihenfolge stehen. Aber ich guck nochmal nach.

Gruß

Gregor

Ich bin mir sicher, dass diese Anweisungen in der richtigen Reihenfolge stehen.

Der Präprozessor macht so nur Textersetzungen, und das in genau der Reihenfolge, wie du sie da hinschreibst.

Du hast also ein ganz anderes Problem.

combie:
Du hast also ein ganz anderes Problem.

Hmpf ja, das fürchte ich.

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.

Gruß

Gregor

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.

Gruß

Gregor