Hallo,
ich möchte gerne eine Klasse schreiben, bzw. bereits getan.
Die Klasse (zum Ansteuern einzellner oder mehrerer LCDs) erscheint mir
sehr korrekt, es gibt keine Fehler beim Kompillieren und der Code hat
als C Variante (also ohne Klasse) funktioniert.
Das Problem ist: nach Erstellung des Programms ist die .hex Datei für
den Programmspeicher nur etwa 189 Bytes groß und das ist definitiv zu
wenig.
Ich hab's probiert und das "Programm" läuft nicht.
Ich benutze idR Makefiles, würde aber auch die Kommandozeile benutzen,
würde ich denn die korrekten Optionen für meinen Fall wissen.
Hier mal das Makefile (von Avr Studio):
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)
Das ist jetzt die Standard kompilliermethode für C Programme, ich weiß
nicht ob man bei C++ andere Flags braucht.
Vielleicht gibt's ja hier den Ein oder Anderen, der selbst in C++
entwickelt und mir weiterhelfen kann. :)
Danke schonmal :)
Gruß Marcel
Was ist denn genau im Binary angekommen? Hast du's mal disassembliert
oder dir wenigstens die Symboltabelle angesehen?
Btw., {UNIX|GNU} make benutzt per Konvention CXX für den C++-Compiler
und CXXFLAGS für die Compileroptionen dafür. CPP ist der
C-Präprozessor, CPPFLAGS sind die Optionen für das Präprozessieren.
Spielt bei explizit geschriebenen Regeln zwar keine große Geige, aber
man tut im Allgemeinen gut daran, sich an Konventionen zu halten, weil
das am wenigsten Verwirrung stiftet auf Dauer.
Marcel schrieb:> Vielleicht gibt's ja hier den Ein oder Anderen, der selbst in C++> entwickelt und mir weiterhelfen kann. :)
Bestimmt, dafuer muesstest du aber ein uebersetzbares Minimalprojekt und
wenigstens die Ausgaben eines deiner Versuche posten.
so, Problem gelöst.
(ja: ich hatte in dem Programm auch ein Objekt von der Klasse erstellt)
woran es lag, weiß ich nicht genau, aber ich nehme an es lag daran, dass
ich Klasse und Methoden alles in einer .h Datei hatte.
Nach dem ich Klasse und Methoden in .h und .cpp aufgeteilt hatte lief es
dann.
Danke trotzdem :)
Marcel
Marcel schrieb:> woran es lag, weiß ich nicht genau, aber ich nehme an es lag daran, dass> ich Klasse und Methoden alles in einer .h Datei hatte.
»ich nehme an...«
Assumptions are the root of all evil.
Eine .h-Datei wird durch den Präprozessor genau an der Stelle
reingezogen, wo das #include steht. Was da drin steht, ist dem
Präprozessor sche***egal, und der Compiler guckt sich nur an, ob
das gültiger C++-Code ist (der bekommt zwar noch eine Info darüber,
dass das aus einem .h stammte, aber die ist nur dafür da, damit er
den Debugger entsprechend leiten kann, sonst interessiert den das
nicht).
Zwar ist es nicht sinnvoll, die komplette Implementierung der Klasse
in eine .h-Datei zu packen (abgesehen von inline-Implementierungen
natürlich), aber solange die .h-Datei nicht von mehreren .cpp-Dateien
reingezogen wird, sollte das keinen Unterschied für den Compiler
ergeben. In letzterem Falle würdest du aber nicht zu wenig an
Implementierung "sehen", sondern zu viel, d. h. der Linker müsste
sich dann beklagen, dass er bestimmte Dinge zweimal bekommen hat.
Jörg Wunsch schrieb:> Zwar ist es nicht sinnvoll, die komplette Implementierung der Klasse> in eine .h-Datei zu packen (abgesehen von inline-Implementierungen> natürlich), aber solange die .h-Datei nicht von mehreren .cpp-Dateien> reingezogen wird, sollte das keinen Unterschied für den Compiler> ergeben.
Ausser der Header wurde irgendwann mal als Kopie von einem anderen
angelegt und dabei vergessen, den Header-Guard anzupassen. Das kann dann
zu den lustigsten Effekten führen ;-)
Andreas
Andreas Ferber schrieb:> Ausser der Header wurde irgendwann mal als Kopie von einem anderen> angelegt und dabei vergessen, den Header-Guard anzupassen.
Oh ja, dieses fiese Problem kenne ich auch. Sowas kann einen echt dazu
bringen, an sich selbt zu zweifeln.
Dann war das anscheinend bei mir das Problem.
Ich hatte noch ein anderes Projekt mit der header Datei.
Wenn ich einen Fehler im aktuellen Programm hatte (beim Kompillieren)
und bin dann zum Problem gesprungen, war ich plötzlich in der
gleichnamigen header Datei des anderen Projekts.
Habe ich kein Fehler gemacht, wurde die aktuelle header Datei
verwendet/kompilliert und alles war problemlos.
War schon merkwürdig und ich wusste echt nicht woran es lag.
Gruß
Marcel schrieb:> Dann war das anscheinend bei mir das Problem.
Das lässt sich leicht feststellen:
Benutzt du Include Guards?
Wenn ja, ist dir einer untergekommen, der nicht mit dem
Dateiinhalt/Dateinamen übereingestimmt hat?
Was auch oft fies ist, sind Include-Pfade die man dem Compiler pauschal
vorgibt. Da werden dann schon mal includes reingezogen, die man so nicht
oder von einem ganz anderen Verzeichnis haben wollte.
1 oder 2 Include Pfade sind ok. Ich hab aber auch schon Projekte
gesehen, bei denen mehr als 20 Include Pfade vorhanden waren, weil die
verschiedenen Basisfunktionalitäten in entsprechend viele
Subverzeichnisse aufgeteilt wurden. Da dann nachzuvollziehen, welcher
include von welchem Verzeichnis kommt, ist eine Sysiphusarbeit.
Moral von der Story: Organisation ist gut. Übertreibt man es aber, dann
wird sie zum alles behindernden Selbstläufer.
Karl heinz Buchegger schrieb:> Moral von der Story: Organisation ist gut. Übertreibt man es aber, dann> wird sie zum alles behindernden Selbstläufer.
Das Problem an der Story ist ja nicht die Organisation, sondern die
Faulheit einfach alle Include-Pfade einzubinden, statt die Dateien mit
Pfad zu includen.
