Wie kommst du auf dieses Konstrukt? Wieso nicht einfach:

DoThing1();
DoThing2();
DoThing3();

Warum rufst du Next() in den Funktionen auf? Das dürfte Aufgabe des Aufrufers sein (kommt natürlich darauf an, was die Funktionen tatsächlich machen).

for (int i = 0; i < 3; i++)
{
     switch (i)
     {
          case 0:
          DoThing1();
          break;
          case 1:
          DoThing2();
          break;
          case 2:
          DoThing3();
          break;
     }
}

Daraus würde ich:

DoThing1();
DoThing2();
DoThing3();

machen, da du genau das erreichst..

bres schrieb:

void Next(state)
{
     switch (state)
     {
          case INITIAL:
          DoThing1();
          break;
          case THING1:
          DoThing2();
          break;
          case THING2:
          DoThing3();
          break;
          case THING3:
// do nothing -- exit
          break;
    }
}
void DoThing1()
{
     // Do "thing 1"
     Next(THING1);
}

Warum rufst du nicht einfach DoThing2 auf, anstatt das über Next zu machen?

So wie ich das sehe rufst du durch eine Schleife erst DoThing1 auf, was dann DoThing2, was dann DoThing3 aufruft. Danach rufst du DoThing2 über die Schleife auf, was dann DoThing3 aufruft.. Dann nochmal DoThing3. Ist das gewollt?

for(int i = 0; i < 3; ++i)
{
    for(int j = i; j < 3; ++j)
    {
        DoThing(j);
    }
}

Und in void DoThing(int n) tust du dann die verschiedenen Sachen, die zu tun sind, rein...

Wenn das Programm nur klein ist bzw. die Anzahl der abzuarbeitenen Punkte, dann kann man auch auf die Schleife verzichten

Falls man tatsächlich Fallunterscheidungen machen muß, dann würde ich in Assembler erstmal versuchen, die Funktionen mit Adresse und bißchen Rechnerei anzusteuern und je nachdem, wieviel Speicherplatz die Funktion braucht, als Grundwert, sowas wie 40 oder 100 oder was auch immer

and al,0f
mul al 20 ;oder einfach nach links shiften und basiswert draufaddieren
add bl,al

..habe aber irgendwo auch schon mal im Forum eine tolle (kurze) c++ Variante für Morsecode-Übersetzer gefunden, aber die finde ich jetzt nicht auf die schnelle. Wie man aber sieht, gibt es viele Lösungen, und die sind meist alle OK, denn:

premature optimization is the root of all evil

premature optimization is the root of all evil

langsam nervts gewaltig

DoThing1();
DoThing2();
DoThing3();

void DoThing1()
{
     DoThing2();
}
void DoThing2()
{
     DoThing3();
}
void DoThing3()
{
     break;
}

Was zu Hölle? Ich glaube ich brauch gar nichts mehr sagen... hast du den Sinn von Funktionen verstanden?

@Bashar: Was man hier nicht alles lernt ^^

Sorry das ich nicht gleich zurück geschrieben habe! Aber schon mal vielen Dank für eure Hilfe!

Würde der Code von mir optimiert bzw. verbessert so aussehen?

DoThing1();
DoThing2();
DoThing3();

void DoThing1()
{
     DoThing2();
}
void DoThing2()
{
     DoThing3();
}
void DoThing3()
{
     break;
}

DoThing3 sollte nicht einmal compilieren, also kann's wohl kaum richtig sein.

Auf den Ansatz bin ich aufgrund der Aussage von Flo gekommen...hmmmmmm aber die FOR Schleife ist doch sinnlos oder nicht?

Ja, praktisch alle Kontrollstrukturen in deinem ursprünglichen Code waren nicht sinnvoll angewendet. Deine Verbesserung ist auch schon fast richtig. Hättest du sie mal ausprobiert, wäre dir der Fehler auch sofort aufgefallen, denn, wie gesagt, durch den Fehler compiliert das nicht einmal.

Hmmmm ok, aber was gibt es hier für eine Möglichkeit anstatt break? Der Lösungsansatz zu meinen Code oben war vorgegeben. Dieser lautete : Lassen Sie aus den Programm die Heißluft entweichen, indem Sie die
Schleife entrollen bzw. die Prozeduraufrufe, startend mit Next(INITIAL), expandieren!

Irgendwie glaube ich, du hast ein paar Grundlagen ganz falsch verstanden. Wie lernst du nochmal, in der Schule? Wenn du auf so eine Sache kommst wie die Funktion oben, dann denkst du vielleicht dass Funktionen irgendwelche Makros sind, oder?

Ich würde mal sagen eine Funktion und ein Makro sind ähnlich...

Sie sind weitgehend identisch. Die zwei Unterschiede sind die Linkage (was du richtig erkannt hast) und das Detail, dass Macros primitiv-rekursiv, Funktionen aber μ-rekursiv sind.