Gast
#4141011
Ich hab hier (schwer verhunzten) Arduino-Code den ich auf einen anderen uC portieren möchte.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
Warum wird bei dem Wort 'case' schon ein Fehler erkannt?
Gast
#4141019
Weil deine IDE keinen echten Parser und Präprozessor verwendet, sondern etwas einfacheres. Das ist üblich und wird sich ggf. ändern, wenn LLVM sich flächendeckend durchsetzt. Und case ohne switch ist halt illegal.
Gast
#4141061
Meenste? Meine IDE ist Eclipse + ARM toolchain. Könnte auch an was anderem liegen. Ich bekomm praktisch bei allem was ich eintrage nen Syntax Error. Als ob ich in diese .hpp Datei keinen Code schreiben darf...
Verteiler schrieb: > Ich bekomm praktisch bei allem was > ich eintrage nen Syntax Error. Als ob ich in diese .hpp Datei keinen > Code schreiben darf... Weiterhin einen Fehler der beim Mouseover angezeigt wird oder auch beim compilieren? Wenn nur beim Mouseover dann einfach ignorieren. Wenn beim compilieren die Fehlermeldung posten.
int i; i=1; wie groß ist i in code?
Gast
#4141105
Langsam versteh ich das...
Der Compiler sagt zwar, daß der Code fehlerhaft ist. Aber da der Code im
Moment noch gar nicht aufgerufen wird, und deswegen auch nicht in ein
Binärfile gegossen wird, läuft die Toolchain sauber durch.
Auch kann man ausserhalb einer Funktion dem Compiler in einer anderen
Datei nicht einfach Code vor die Füße werfen. Bei der
Arduino-Philosophie ist das anders, da scheint's zu gehen.
Lutz H. (luhe) schrieb:
>wie groß ist i in code?
0 Bytes, weil es nicht benutzt wird.
"Wir irren uns emopor." (Harald Lesch)
Verteiler schrieb: > Der Compiler sagt zwar, daß der Code fehlerhaft ist. Aber da der Code im > Moment noch gar nicht aufgerufen wird, und deswegen auch nicht in ein > Binärfile gegossen wird, läuft die Toolchain sauber durch. Ich fürchte es ist umgekehrt. Der Editor parsed den Code auf Datei-Basis und für ihn steht das case in der Datei driver_B.h ohne switch() alleine in der Gegend herum. Daher merkt er das als Fehlerhaft an. Der Compiler sieht aber ein switch() { case 2: bla bla } was vollkommen korrekt ist, weswegen er keinen Fehler meldet und einen ausführbaren Code erzeugt. Ich weiß, dass man da geteilter Meinung sein kann, aber ich würde denjenigen, der solch einen zerfledderten Code schreibt (Und das auch noch mit invetierter Logik bei den #ifndef) mit einer Neunschwänzigen Katze durch alle Gassen treiben. Wenn man die cases versehentlich doppelt vergibt, sucht man sich einen Wolf warum das so ist und wenn man Lücken lässt, wundert man sich, warum nix passiert. Gruß Ulrich
Wie wäre es denn mit einer weiteren "}" nach dem letzten #endif?
Wer so was schreibt, dem gehört der A.... verhauen. Aber richtig.
Markus F. schrieb: > Wer so was schreibt, dem gehört der A.... verhauen. Aber richtig. Vor allen Dingen könnte man diesen ganzen switch-case schon mal in Frage stellen und sich fragen, warum der Autor hier keine virtuellen Funktionen auf abgeleiteten Klassen benutzt hat. Dann würde sich das ganze Problem von alleine in Luft auflösen. Fallunterscheidungen, die auf einer Typkennung beruhen, sind in C++ meistens durch Polymorphie besser zu lösen.
Markus F. schrieb: > Wer so was schreibt, dem gehört der A.... verhauen. Aber richtig. Äh, wen meinst du jetzt? Mich? In der Quelle sind 2x "{" aber nur 1x "}".
Joe F. schrieb: > Äh, wen meinst du jetzt? Jeden, der switch()-cases über include-Dateien verstreut.
Ulrich P. schrieb: > ich würde > denjenigen, der solch einen zerfledderten Code schreibt (Und das auch > noch mit invetierter Logik bei den #ifndef) mit einer Neunschwänzigen > Katze durch alle Gassen treiben. Vater, vergib ihnen, denn sie wissen nicht, was sie tun.
Gast
#4142765
Autor: Karl Heinz (kbuchegg) (Moderator) schrieb: >Vor allen Dingen könnte man diesen ganzen switch-case schon mal in Frage >stellen und sich fragen, warum der Autor hier keine virtuellen >Funktionen auf abgeleiteten Klassen benutzt hat. Dann würde sich das >ganze Problem von alleine in Luft auflösen. Wie schon in meinem Eingangspost geschrieben: Das ist Arduino-Bastlercode von der eher schrilleren Sorte. Vieleicht hat der Bursche der das schrieb von virtuellen Funktionen keine Ahnung. In der Sw gehts um das Einbinden en von ca 15 unterschiedlichen LCDs. Die Pflicht hat er gut hinbekommen, an der Kür hapert's den Arduinern halt gelegentlich. Der Bursche hat den gesamten (!) Code für die Displaytreiber in .h Dateien geschrieben. Schon drollig irgendwie.
Verteiler schrieb: > Wie schon in meinem Eingangspost geschrieben: Das ist > Arduino-Bastlercode von der eher schrilleren Sorte. Und warum nimmst du diesen Scheiß dann? Meine Mutter hat mir vor mehr als einem halben Jahrhundert beigebracht, dass man Süßigkeiten die auf der Straße liegen liegen lässt.
Hannes Jaeger schrieb: > Meine Mutter hat mir vor mehr > als einem halben Jahrhundert beigebracht, dass man Süßigkeiten die auf > der Straße liegen liegen lässt. Das sieht ein Rheinländer aber ganz anders... Oliver
Ohne einen Streit über den Sinn oder Unsinn von C++ gegenüber C auslösen zu wollen, aber C++ verleitet einfach dazu nach dem Motto "Der Compiler wirds schon richten" zu arbeiten. Das treibt dann solche Stilblüten... Man kann doch auch 100 verschiedene Displays einbinden, in dem man einen festen Satz von Funktionen gleichen Namens definiert. Und Funktionen, die von einem Display nicht unterstützt werden, kann man entweder leer definieren oder zumindest in der Debug-Version mit einem return -1 ausstatten, dass man weiß, dass es das nicht gibt, was man da haben möchte. Flexible Anbindung von Treibern macht der Kernel doch auch in ANSI-C mit ein paar C99 Extentions. Es ist einfach unfassbar, warum solch ein Murks da oben verzapft werden muss. Aber alles Aufregen nützt nix, allen Rheinländern sollte man in dem Fall raten, die besonders harten Klümpchen aufzuheben und sie gezielt nach dem Author dieses Stücks Code zu werfen :)
Ulrich P. schrieb: > Ohne einen Streit über den Sinn oder Unsinn von C++ gegenüber C auslösen > zu wollen, aber C++ verleitet einfach dazu nach dem Motto "Der Compiler > wirds schon richten" zu arbeiten. Das treibt dann solche Stilblüten... Das hat doch überhaupt nichts mit C++ zu tun. Den selben Murks könnte man ganz genauso auch in C schreiben.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.