switch/case über mehrere Dateien

[Verteiler (Gast)]

Ich hab hier (schwer verhunzten) Arduino-Code den ich auf einen anderen 
uC portieren möchte.

in myFile.cpp:
void myClass::select(int i)
{
  switch(i)
  {
#ifndef DISABLE_VARIANT_A  //definiert
  #include "driver_A.h"  //nicht includiert
#endif
#ifndef DISABLE_VARIANT_B // nicht definiert
  #include "driver_B.h"  // includiert
#endif
#ifndef DISABLE_VARIANT_C //definiert
  #include "driver_C.h"  //nicht includiert
#endif
}

in driver_B.h:
case 2:    // <--Hovertext: Syntax Error
  bla
  bla

Warum wird bei dem Wort 'case' schon ein Fehler erkannt?

[Marc (Gast)]

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.

[Verteiler (Gast)]

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...

[Sebastian V. (sebi_s)]

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.

[Lutz H. (luhe)]

int i;
i=1;
wie groß ist i in code?

[Verteiler (Gast)]

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)

[Ulrich P. (uprinz)]

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

[Joe F. (easylife)]

Wie wäre es denn mit einer weiteren "}" nach dem letzten #endif?

[Markus F. (mfro)]

Wer so was schreibt, dem gehört der A.... verhauen. Aber richtig.

[Karl H. (kbuchegg)]

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.

[Joe F. (easylife)]

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 "}".

[Markus F. (mfro)]

Joe F. schrieb:
> Äh, wen meinst du jetzt?

Jeden, der switch()-cases über include-Dateien verstreut.

[Eric B. (beric)]

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.

[Verteiler (Gast)]

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.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

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.

[Oliver S. (oliverso)]

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

[Ulrich P. (uprinz)]

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

[Rolf M. (rmagnus)]

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.