Mittels Switch Case zwischen Unterprogrammen in der main wechseln

Hi

Da 'Unterprogramm' hier eher 'Funktion' sein wird: ja
Sehe kein Problem in Deinem Code.
Wenn doch, wird der Compiler Dir schon sagen, was Ihn stört - musst den 
ersten Compiler-Versuch ja nicht erst bei 4000 Zeilen Quelltext starten.

MfG

PS: Oh, da war gar Nichts in der switch-Anweisung drin :/ - Das hätte 
der Compiler aber wohl auch angemeckert.

Du kannst das ganze auch gleich zu einem Zustandsautomat (State machine) 
entwickeln, so dass man zwischen den Unterprogrammen/Zuständen wechseln 
kann.

typedef enum
{
    MANUAL = 0,
    SAR,
    TRACKING
} state_t;

state_t state = MANUAL;

int main(void)
{
    while(1)
    {
        switch(state)
        {
            case MANUAL:
                manual();
                if(.....)
                    state = SAR;
                break;
                case SAR: sar();       break;
                case TRACKING: tracking();  break;
            default:
                puts("Fehler");
                state = MANUAL;
        }
    }
}

Moin,

Das schoene an C ist, dass man da auch prima solche kurzen Konstrukte 
schreiben kann - ganz ohne switch case:

1

int wahl;

2

void (*machwasichwill[])(void)={manuell,sar,tracking};

3

4

/* ... */

5

6

wahl=1;

7

machwasichwill[wahl]();

Obacht: wahl darf hier nur 0,1 oder 2 sein - sonst droht ewige 
Verdammnis.


Gruss
WK

Jetzt frag ich mich gerade, warum der Beitrag von  Dergute Weka und 
einigen anderen negativ bewertet wurde.

Denn was hier beschrieben wird, ist die Dispatcher Liste in 
ereignisgesteuerten Systemen ohne Preemption. Sowas wird gerne 
verwendet, wenn die System klein und leichtgewichtig sein sollen. Z.B. 
wenn es wenig Platz für einen Stack gibt.

Die Liste "machwasichwill" ist hier statisch, aber sowas kann man 
natürlich auch dynamisch gestalten, mit Prioritäten versehen usw. Damit 
kann man dann ganz unterschiedliche Scheduler konstruieren und ein sehr 
mächtiges Laufzeitsystem bauen.

Moin,

Possetitjel schrieb:
> Dergute W. schrieb:
>
>> Das schoene an C ist, [...]
>
> Dein Beispiel ist der schlagende Beweis, dass Schönheit im
> Auge des Betrachters liegt.

Hihi, jepp - so isses.

Gruss
WK

Rolf H. schrieb:
> Jetzt frag ich mich gerade, warum der Beitrag von  Dergute Weka und
> einigen anderen negativ bewertet wurde.

Unleserlich, Fehler trächtig, schlecht(er) zu Debuggen, unnötig das 
einem Anfänger zu zeigen (ich fand's interessant, WTF).

Also, wenn ich da gewertet hätte.

Moin,

HildeK schrieb:
>
> Zugegeben, dies kannte ich nicht.
> Ich glaube auch nicht, dass diese Lektion ideal für Anfänger (der TO hat
> sich so bezeichnet) ist. Mir jedenfalls gefällt sein (korrigierter)
> Vorschlag besser, weil für mich übersichtlicher.
Ja, ist mir klar, dass das fuer "Anfaenger" erstmal schwere Kost ist. 
Aber:
a.) Das lesen ja nicht nur Anfaenger und b.) Ich schrub ja auch, dass 
ich es schoen finde, dass man bei C auch solche Konstrukte schreiben 
kann. Und ich schreibte nicht, dass die Methode mit den 
Funktionspointern die einzig und alleine Seligmachende ist.

> Kann diese Methode auch Funktionen mit unterschiedlicher Parameterlisten
> handeln oder nur leere bzw. gleiche?
Die Methode wuerde ich nur anwenden, wenn alle Funktionen gleiche Typen 
bei den Argumenten und Rueckgabewerten haben. Sonst waere mein 
aesthetisches Empfinden sehr beeintraechtigt und es wird eine ueble 
Casterei um den Compiler zu beruhigen und ich wuerd' mal nicht voellig 
ausschliessen, dass da auch mal Bloedsinn passieren kann.

Gruss
WK

Dergute W. schrieb:
> Die Methode wuerde ich nur anwenden, wenn

Jo, nur für Eventualitäten. Wie werden solche Funktionen bezeichnet, 
bzw. Suchbegriff(e)?

Teo D. schrieb:
> Unleserlich, Fehler trächtig, schlecht(er) zu Debuggen, unnötig das
> einem Anfänger zu zeigen (ich fand's interessant, WTF).

Zum Teil berechtigt.

Unleserlich. Nun, das hat C so an sich. Man nennt es manchmal auch Krieg 
der Sterne.

Fehlerträchtig. Nein, es ist ein Array von Funktionen. Da kann man 
nichts falsch machen, wenn man es einfach so abschreibt.

Schlechter zu Debuggen. Nein, denn es ist der Semantik nach ein 
switch-Statement. Nur dass im switch-Statement die Sprungadressen 
verdeckt codiert werden und hier sichtbar sind.

Unnötig, das einem Anfänger zu zeigen. Richtig, aber hier lesen auch 
Fortgeschrittene mit. Den hilft es auf jeden Fall. Und der Anfänger kann 
bei Bedarf mal drauf zurück greifen.

Ich denke positives und negatives halten sich die Waaage.

Rolf H. schrieb:
> Fehlerträchtig. Nein, es ist ein Array von Funktionen. Da kann man
> nichts falsch machen, wenn man es einfach so abschreibt.

Na ich stell mir da immer gleich ein größeres Konstrukt vor und da 
scheint es schnell, chaotisch/unübersichtlich zu werden.
...
...
...
Ach Quatsch. Wenn sich Auge und Hinterkopf erst dran gewöhnt hat....

Rolf H. schrieb:
> Unnötig, das einem Anfänger zu zeigen. Richtig, aber hier lesen auch
> Fortgeschrittene mit.

Meine Worte!
War halt nach eventuellen Gründen gefragt und naja, die gingen mir 
aus. ;)

Moin,

Also sooo exotisch sind Arrays von Funktionspointern, bzw. structs, die 
als Member Funktionspointer enthalten auch wieder nicht. Linux ist voll 
davon. Une wenn ich in andere Kernel gucken koennte, bin ich mir sicher, 
dass es das dort genauso gibt.
Klar, um ein HelloWorld zu programmieren, brauch ich das nicht. Und wenn 
ich in Java oder C++ in irgendwelchen wilden Vererbungen schwelg', macht 
der Compiler halt die Drecksarbeit ohne dass ich den leisesten Schimmer 
hab, wie das dann wirklich funktioniert.

Gruss
WK

Hi

Dieter schrieb:
> Unterschiedliche Versionen per
> Quelltextänderung ist Pfusch.

Und ich dachte, wenn ich den Quelltext ändere, wäre eine neue 
Versions-Nummer fällig - dabei ist Das bisher nur Pfusch gewesen :/

Ein Glück, daß heute nicht noch erst über Alpha und Beta gegangen werden 
muß, wie Das wohl Früher so war.
Ein Hoch auf die neue Technik!

Wie sonst werden denn neuere Versionen 'entwickelt', wenn nicht durch 
Anpassung des Quelltext?
'Hmm - Heute compiliere ich Mal ohne Optimierung und schreibe ein Smilie 
in den Kommentar des Make-File'

Mit der Bitte um Aufklärung