Gerade gefunden: Beitrag "Re: for(;;) bedeutung?"> Genau da haben wir das Problem mit dem redundanten Code sogar> noch in verschärfter Form. Natürlich kann man diese Schleife
1
> for(;;) {
2
> // Codeabschnitt A
3
>
4
> if(bedingung)
5
> break;
6
>
7
> // Codeabschnitt B
8
> }
> so umstellen, dass die Abbruchbedingung am Anfang der Schleife steht:
1
> // Codeabschnitt A
2
>
3
> while(!bedingung) {
4
> // Codeabschnitt B
5
>
6
> // Codeabschnitt A
7
> }
> Jetzt steht aber der Codeabschnitt A zweimal da.
Die Lösung mit Schleife mit Hineinsprung sähe so aus:
Bei deiner Variante sieht es merkwürdig aus, egal ob A kurz oder lang
ist ehrlich gesagt.
(Abgesehen davon, daß man je nach Anwendung A gleich so formulieren
kann, daß es Erfolg oder Mißerfolg als Rückgabewert meldet, und dann
gleich als Bedingung nimmt. zumindest, wenn wenn man Funktionen hat :-))
Aber Geschmackssache!
Das sind alles Nebelkerzen. Die relevante Frage lautet:
Warum hat C kein DO-UNTIL (oder "mitten in die Schleife springen")?
Oder: Warum beschränkt man sich beim Beschreiben boolescher Funktionen
nicht auf nand und nor (immerhin vollständiges System)?
Oder: Warum verwenden wir nur 26 Buchstaben und Worte mit so vielen
Buchstaben, wären 5000 verschiedene Zeichen nicht effizienter?
Oder: Warum setzt sich durch, was am einfachsten erlernbar,
kommunizierbar und wiedererkennbar ist?
Oder: Warum wählt man von 2 Varianten nicht ohne irgend einen Vorteil
freiwillig die umständlichere Variante?
a. for (;;)
b. *L.JP [...] *HERE [...] *RP.not(bedingung)
c. nur ein kyrillisches Zeichen und die 2 Sprungmarken, um das alles zu
beschreiben
(Man braucht die Bedeutung dieses kyrillischen Zeichens schließlich nur
einmal lernen, dann ist es intuitiv benutzbar!)
Was ist besser?
Lars R. schrieb:> Oder: Warum verwenden wir nur 26 Buchstaben
Nun, zumindest hier gibt es real existierende und schon sehr lange
praktizierte Gegenentwürfe. Ob "unser" Verfahren "besser" ist? Es ist
primär anders. Und vermutlich wirklich leichter zu erlernen, was aber
die den Gegenentwurf nutzenden nicht davon abbringt, ihr System
beizubehalten.
Rufus Τ. F. schrieb:> Lars R. schrieb:>> Oder: Warum verwenden wir nur 26 Buchstaben>> Nun, zumindest hier gibt es real existierende und schon /sehr lange/> praktizierte Gegenentwürfe. Ob "unser" Verfahren "besser" ist? Es ist> primär anders. Und vermutlich wirklich leichter zu erlernen,> was aber> die den Gegenentwurf nutzenden nicht davon abbringt, ihr System> beizubehalten.
Im Laufe der Jahrhunderte und in Gegenwart von Alternativen scheinbar
doch. Auch viele chinesische Zeichen werden im Alltag nicht verwendet.
Lars R. schrieb:> Warum hat C kein DO-UNTIL
Hat es doch, in Gestalt der do-while-Schleife,
wenn auch mit negierter Angabe der Bedingung.
> (oder "mitten in die Schleife springen")?
Die Formulierung soll offenbar die Schleife mit Hineinsprung
als abstruse Idee erscheinen lassen. In Wahrheit ist diese Schleife
aber genau jene Struktur, durch welche while-Schleifen tatsächlich
im compilierten Code meistens realisiert werden.
Josef G. schrieb:> Lars R. schrieb:>> Warum hat C kein DO-UNTIL>> Hat es doch, in Gestalt der do-while-Schleife,> wenn auch mit negierter Angabe der Bedingung.>>>> (oder "mitten in die Schleife springen")?>> Die Formulierung soll offenbar die /Schleife mit Hineinsprung/> als abstruse Idee erscheinen lassen. In Wahrheit ist diese Schleife> aber genau jene Struktur, durch welche while-Schleifen tatsächlich> im compilierten Code meistens realisiert werden.
Ich stimme Dir zu, dass meine Fragen provokativ formuliert waren und Du
brauchst darauf nicht antworten. Dort wo Du es aber dennoch tust,
weichst Du jeweils der Frage aus. Die Fragen waren: Warum hat C kein
DO-UNTIL und warum hat C nicht die Schleife mit Hineinsprung?
Die Fragen hatte ich formuliert als Antwort auf Deine Kritik des
C-Konstruktes for(;;). Du hattest Deine Konstrukte schließlich mit der
for- bzw. while-Schleife verglichen und impliziert, dass Deine Variante
effizienter sei. Und ich habe gefragt, warum C wohl ein solches
Konstrukt dennoch nicht hat. Darauf nimmst Du einfach keinen Bezug,
sondern kommst mit etwas anderem.
Edit: Ok, zu Deiner ersten Antwort war meine Frage vielleicht zu
ungenau:
Warum hat C nicht zusätzlich das DO-UNTIL? Damit ließe sich doch viel
effizienterer Code erstellen.
Josef G. schrieb:> Lars R. schrieb:>> warum C wohl ein solches Konstrukt dennoch nicht hat.>> Das weiss ich nicht.
Meiner Ansicht nach wäre es hilfreich, wenn Du einen C-Experten suchst,
dessen Antworten Du akzeptierst und ihn dazu befragst.
Lars R. schrieb:> Warum hat C nicht zusätzlich das DO-UNTIL?
Aus dem selben Grund aus dem C auch kein ifnot(), kein whilenot() und
auch Pascal kein repeat-while hat: weil es redundant und überflüssig
wäre, denn es gibt bereits den separaten not operator !, damit kann man
es sich so kombinieren wie man es braucht.
Bernd K. schrieb:> Aus dem selben Grund aus dem C auch kein ifnot()
Perl kennt ein "unless". ;-)
Macht sich manchmal gut für die Lesbarkeit, weil man in Perl die
Bedingung auch hintenan stellen kann.
1
save_file() unless $readonly;
Aber ich zweifle, dass die Bome-CPU jemals Perl sehen wird …
Jörg W. schrieb:> Aber ich zweifle, dass die Bome-CPU jemals Perl sehen wird …
Das ist nun in jeder Hinsicht kein Verlust...
Ruby kennt die hinten angestellte Bedingung incl. unless auch.
