Wäre das etwas?

VB.NET-Quellcode

1. Private ExitFlag As Boolean
2. Sub Main(args As String())
3. While Not ExitFlag
5. End While
6. End Sub

Dann einfach ExitFlag auf True setzen, wenn der User das will.

Nein, ist ja eine Bedingung. Das ist ja richtig was zum knobeln.

Edit:
@VaporiZed
Da ist mir ein totaler Holzhammer eingefallen:

Also wenn du wirklich keine If-Abfragen oder Booleans nutzen möchtest, dann fällt mir auch nur so eine Grütze die @DTFs Antwort ein...

Also wie ich das in C/++ machen würde, wüsste ich. Da würde ich mir stumpf von allen Funktionen die Adressen holen und einfach solange mit ​setjmp/longjmp hin- und herspringen.
Irgendwann kann man halt einfach die Adresse auf abort(); schieben und dann mit ach und krach das Progrämmchen killen.

Ich habe tatsächlich gerade zuerst ​gosub geschrieben... naja, gut dass ich noch nie auf einer echten C64/128 programmiert habe

Wie mein C/++-iger Ansatz nun in .net aussehen würde, weiß ich ehrlich gesagt nicht. In solchen Managed-Sprachen vermeide ich es so gut wie es geht, irgend einen Blödsinn mit ASM und Pointern zu machen.

Ich belasse das hier aber als Mitleserkommentar. Das würde mich ja doch auch interessieren, was sich hier die Leute einfallen lassen.

siycah schrieb:

Da würde ich mir stumpf von allen Funktionen die Adressen holen und einfach solange mit setjmp/longjmp hin- und herspringen.

Das können wir einfacher haben, wird zwar wie ein bool interpretiert, aber ist ja keiner. Aber mit VB oder C#, da fällt mir echt nur Try/Catch ein.


Edit: Wobei while ja doch als Bedingung gewertet werden könnte.

DTF schrieb:

Edit: Wobei while ja doch als Bedingung gewertet werden könnte.

Mein Reden

Anstatt einer ​while kann man aber auch immer:



nehmen

VaporiZed schrieb:

Do
Loop Until ProgramShallEnd()

Aber damit hast du wieder eine boolsche Überprüfung drin. Das ist ja auch nur eine fußgesteuerte bedingte Schleife.

VaporiZed schrieb:

@siycah: Mir fällt zwar notfalls noch das Rabiat-End ein, aber dann sollte ich mich vorher noch um die Aufräumarbeiten kümmern …

Die Aufräumarbeiten sind ja erstmal nebensächlich. Alle Resourcen die dein Programm allokiert wird das Framework dann schon zerstören; das ist mittlerweile auch bei nativen Sprachen und modernen Betriebssystemem der Fall. Außer du meinst natürlich Daten die du noch im RAM hast. In dem Fall definitv raus damit

Normalerweise endet das Programm nach der Schleife. Also setzt du den counter immer auf 0 damit die Schleife weiterläuft, oder verstehe ich das nicht richtig?
Und wenn man das so sieht dann muss in einer For schleife an sich auch irgendwo geprüft werden, ob der Counter weiterhin < 1 ist. Sonst wäre eine For 1 To 1 dasselbe wie ganz ohne Schleife.

Wenn ich eine Konsolenanwendung habe, die nicht ohne Userinput aufhört, dann habe ich eine While Schleife, die weiterhin Eingaben kassiert. Aber die While braucht ja schon nen Bool
Interessehalber welchen Gewinn hätte ich ohne Bool?

Also das heißt für mich das Programm muss einen Weg gehen, ohne jemals eine Kreuzung zu sehen. Also so würde es wirklich ohne erstmal laufen, aber Abschalten ist dann nicht mehr ohne links rechts wählen.


Man kann irgendwas einstreuen das bei bestimmten Input eine Exception wirft. Die darf man aber auch nicht Abfangen weil Catch wäre wieder abgebogen.
Ich gehe auch mal davon aus, dass Parse prüfen wird, ob a aus Ziffern besteht.

Und dann hat die Konsole ja noch den X-Button, wie macht man den aus?

Hm, ein leeres Catch könnte man als nicht abgebogen werten.
Ich sehe nicht den Unterschied, ob ich If hinschreibe oder durch andere Wörter das verschleiere. Entweder der Prozessor muss was prüfen oder nicht.

Der User kann 20 mal was machen danach schaltet das Programm ab, das ist der einzige Weg wie der Prozessor einfach geradeaus laufen kann.

Je mehr ich drüber nachdenke, desto mehr finde ich es geht nicht unbedingt. Allein dadurch das eine Entscheidung getroffen wird, ist das ja schon bedingt, also abhängig von dieser Entscheidung. Auch beim Try/Catch, entweder kann man weiter machen oder nicht, mit der Bedingung ob's funktioniert oder eine Exception geworfen wird.

Woher weißt du z.B. das ein Input > 4 ist? Das ist schon eine Verzweigung

Du könntest für jede denkbare Eingabe eine eigene Methode bauen und verschiebst damit die Verzweigung bis runter auf den User selbst. Aber ich denke Sinn jeder Anwendung ist genau solche Userverzweigungen zu verallgemeinern und in kleinerem Umfang abzuarbeiten mit dann selbsterzeugten Verzweigungen der Verallgemeinerungen.

Also wählst du ein Array Element aus, um in eine Methode zu springen, ich schätze das geht mit Tasks oder Delegaten, da kenn ich mich leider nicht gut mit aus.
Und bei der Hauptschleife hatte ich vermutet, dass die nur läuft weil du den counter immer zurücksetzt. Wenn Programmende das nicht macht dann hört es doch ohne Exception auf.

So etwas wie „Bedingungslose Konsolenapp” gibt es nicht, aber eine „Bedingungslose Kapitulation” z.B. schon – ein Blick ins Lexikon hilft manchmal ganz gut, um die Dinge richtig einordnen zu können, Lexika und Fachbücher wären bestimmt noch besser. „Eine Konsolenapp ohne IF-Anweisungen im Code” müsste man das Ding eigentlich nennen, damit man überhaupt weiß, worum es geht, wenn man so eine merkwürdige Zeile liest, wobei die IF-Anweisung an sich nur ein Konstrukt auf einer höheren Abtraktionsebene ist, extra für den Menschen erschaffen, damit sich der Programmablauf besser lesen lässt – auf Prozessorebene gibt es das so gar nicht, dort wird alles mit Flags (entsprechend gekippten Bits) entschieden und abgearbeitet – und diese Unterscheidung passiert quasi ständig oder laufend. Egal, ob die CPU eine Abzweigung (bedingten Sprung) macht, eine Schleife durchläuft, Do-Loop-While-Until passiert, eine Addition, Subtraktion oder Multiplikation vollführt, es läuft alles mit diesen internen Flags, insofern ist das mit diesem „Code ohne IFs” eher eine Art Selbstbetrug oder Spielerei, die die Wirklichkeit nicht widerspiegelt und vermutlich auf Unwissen basiert oder die Verwechslung einfach nur mit der ersten Abstraktionsebene, die in der Regel mit der Sprache C beginnt, zusammenhängt und dort ihre Quelle hat. Es gibt normalerweise auch keine Assemblerbefehle, die IF heißen und wo man dann einen komplexen Ausdruck zum Abfragen dahinterschreiben kann, aber durchaus Hilfen in den IDEs wie Macros, wo man im Assemblercode eine komplexe IF-Anweisung und noch vieles mehr verwenden kann, damit der Mensch das besser lesen bzw. einfacher schreiben kann – am Ende macht der Compiler daraus eh nur Assemblerbefehle, wo nur Flags unterschieden werden; aus Mnemonics werden dann am Ende einfach nur Zahlen in Binärform vorliegen. Moderne Prozessoren haben mittlerweile explizit sogenannte bedingte Befehle, wo dann diese Flags unmittelbar zu differenziertem Ausführen eines solchen Befehls im Hintergrund führen und zum Einsatz kommen, ohne dass man noch andere Befehle mit Flag-Unterscheidung dafür benutzen muss; auch Befehle mit drei Operanden sind möglich.

Haudruferzappeltnoch schrieb:

Also wählst du ein Array Element aus, um in eine Methode zu springen, ich schätze das geht mit (...) Delegaten

Damit – also z.B. einem Array aus Delegaten – könnte man sehr viel oder vielleicht sogar fast alles lösen – wem der Delegat zu exotisch oder zu kompliziert ist, der könnte auch spaßhalber auf die alte, mittlerweile verhasste und verpönte CallByName-Methode zurückgreifen und dann die Sprünge mit einer Stringvariable kreieren. Egal, ob mit einem Delegaten oder einem Relikt aus ferner Zeit, so etwas wie If Eingabe >= 100 And Eingabe < 1000 Then und ähnliche Ausdrücke könnte man damit auf jeden Fall realisieren oder erfolgreich abfangen – natürlich nicht, indem man ein Array aus 1000 Delegaten und 1000 Unterprogrammen schreibt, sondern man bearbeitet erstmal mathematisch ein wenig die Eingabe, um die Anzahl der Möglichkeiten drastisch zu reduzieren. Wenn die Eingabe ein Integer wäre, könnte man erstmal eine IntegerDivision mit 1000 durchführen (Eingabe\1000), um zu schauen, ob die Zahl unter 1000 liegt, d.h. das Ergebnis dieser IntegerDivision als ArrayIndex nehmen; wenn JA, würde man bei Index 0 einspringen und gleichzeitig wissen, dass die Zahl unter 1000 liegt; im zweiten Schritt dann mit der ursprünglichen Zahl eine IntegerDivision mit 100 durchführen, um zu schauen, ob die Zahl unter 100 liegt (ArrayIndex als Integer wäre dann 0). Wenn sie nicht unter 100 liegt, also ein Catch bei Try und kein Einsprung bei ArrayIndex 0 passiert ist, dann wird sie wohl irgendwo in dem gesuchten IF-Bereich liegen. Dafür bräuchte man nur jeweils einen, also insgesamt zwei Delegaten (oder CallByNames) und zwei Subroutinen, einen fehlerhaften Verweis könnte oder müsste man mit Try-Catch abfangen. Möglicherweise bräuchte man noch ein bis zwei zusätzliche indexierte Subroutinen als Zwischenstationen. Eventuelle (Rück)sprungadressen oder so etwas in der Art könnte man auch als Argumente an die Subroutinen übergeben, wäre aber nicht zwingend notwendig, wenn man solche Aktionen immer wieder neu im Code schreibt, wo dann die Adressen eindeutig klar sind, oder weiß, wie man sie wiederverwenden/recyceln könnte. Informationen könnte man grundsätzlich ganauso austauschen oder übermitteln. Negative Eingabe könnte man mit UInteger oder gleich bei der Eingabe durch casten, umformen, Betrag nehmen, quadrieren & wurzelziehen, Wiederholung der Eingabe, Offset einbauen etc. unterbinden oder abfangen. Man wüsste sogar auch, ob die Eingabe bei größer/gleich 1000 oder unter 100 lag, also hätte quasi auch das Else des IFs parat. Ziemlich viel Aufwand für nur eine IF-Zeile, aber – wie ich am Anfang des Paragraphen schon erwähnt habe – möglich wäre bestimmt fast alles. Ersatz für Abfragen wie If Eingabe = 1, 2, 3, 4, 5 oder = "a", "b", "c", "d", "e" zu schaffen wäre vermutlich etwas einfacher zu realisieren in diesem Kontext.

Kannst du dann nicht die Dinge, die aufgeräumt werden müssen an die EndeRoutine ByRef übergeben, dort aufräumen und dann End aufrufen?
MinMaxParse und Schleife sind aber noch gemogelt.^^
Zwei Methoden die sich endlos gegenseitig aufrufen können das gleiche wie die Schleife nur ohne Prüfung. Aber ich denke mal damit belastet man irgendwie seine Ressourcen.

Hab noch was besseres:

Da wird nichtmal mehr was übergeben. Und auch nicht End aufgerufen. Die Konsole schließt durch Ende der Sub Main