Hallo zusammen, ich verstehe hier den Grund der Warnung nicht. Kann mir jemand weiterhelfen? Es ist vllt nicht der schönste Code, aber er funktioniert und alle Variablen werden benötigt. (Code wurde zur besseren Visualisierung als Bild gepostet) Danke :)
Angehängte Dateien:
-
Warnungen.png
45 KB
Die komplette Ausgabe der Warnings ist leider nicht lesbar.
Achso dein for(i; ...) wird wohl die Ursache sein. Schreib lieber for(; ...)
Domenik schrieb: > aber er funktioniert Auch dann noch, wenn der jeweils gewünschte Buchstabe überhaupt nicht vorkommt?
(prx) A. K. schrieb: > Domenik schrieb: >> aber er funktioniert > > Auch dann noch, wenn der jeweils gewünschte Buchstabe überhaupt nicht > vorkommt? Ich gehe einfach von einer fehlerfreien Übertragung aus 😁. Aber habe noch einen CRC in der aufrufenden Funktion. loeti2 schrieb: > Achso dein for(i; ...) wird wohl die Ursache sein. > Schreib lieber for(; ...) Verdammt, das war's 🙈🙈🙈. Ich habe echt lange überlegt. Danke loeti2 schrieb: > Die komplette Ausgabe der Warnings ist leider nicht lesbar. Die komplette GCC Ausgabe wird von der IDE leider überschrieben, wenn erfolgreich kompiliert wird. D.h. um die GCC-Ausgabe anzuzeigen, muss man einen Fehler einbauen.
Wie oft wird eigentlich eine for-Schleife ohne Bedingung wiederholt? for (i; ; i++)
Domenik schrieb: > Es ist vllt nicht der schönste Code Ja, vor allem wenn man den Schleifenzähler innerhalb der Schleife noch wild verändert. Voll übersichtlich und überhaupt nicht fehleranfällig ..... oder vielleicht doch?
OMG schrieb: > Ja, vor allem wenn man den Schleifenzähler innerhalb der > Schleife noch wild verändert. Wird er doch gar nicht. Wird nur im Kopf der Schleifen geändert. Wie es sich gehört. Eigentlich ist es egal ob man einen Parser mir goto oder break baut. Man nimmt hat das, was einem besser liegt. Natürlich gibts auch andere Methoden. Aber wirklich schöner wirds damit auch nicht. Die vorgefertigten strtok(), sscanf() und ihre Geschwister könnte man natürlich auch verwenden.
Domenik schrieb: > (prx) A. K. schrieb: >> Domenik schrieb: >>> aber er funktioniert >> >> Auch dann noch, wenn der jeweils gewünschte Buchstabe überhaupt nicht >> vorkommt? > > Ich gehe einfach von einer fehlerfreien Übertragung aus 😁. Aber habe > noch einen CRC in der aufrufenden Funktion. Das hilft dir nicht. Stefan hat das schon verstanden: Stefan ⛄ F. schrieb: > Wie oft wird eigentlich eine for-Schleife ohne Bedingung wiederholt? > > for (i; ; i++) Ich würde dir generell empfehlen, die Syntax einer for-Schleife noch einmal genau nachzulesen. Das hätte dir vermutlich auch die Ausgangsfrage beantwortet: i als Statement hat keinen Effekt. Tut nix. Egal ob mitten im Code:
1 | int i = 0; |
2 | i++; |
3 | i; |
Oder eben wie bei dir an erster Stelle im Schleifenkopf. Und im Übrigen gibt es für deine Aufgabe auch bereits Bibliotheksfunktionen wie strchr / strstr, die den Code lesbarer machen und dir dumme Fehler beim Implementieren ersparen können. MfG, Arno
Stefan ⛄ F. schrieb: > Wie oft wird eigentlich eine for-Schleife ohne Bedingung wiederholt? > > for (i; ; i++) for(;;) ist eine Endlosschleife, das würde dir auch dein C oder C++ Grundlagenbuch berichten.
Btw, das Gehampel mit tmpStr ist unnötig (und falsch) - atoi hört eh beim ersten nicht-Ziffer-Zeichen auf ... Und "index" ohne Prüfung benutzen schreit nach Speicherfehler.
Ganz abgesehen davon, dass das ein furchtbarer Programmierstil ist. Wenn schon, dann so:
1 | while(string[i++] != ':'); |
:
Bearbeitet durch User
EAF schrieb: > for(;;) ist eine Endlosschleife, das würde dir auch dein C oder C++ > Grundlagenbuch berichten. Wollte ich auch gerade schreiben for(i; "unbekannte bedingung"; i++) kann nicht funktionieren
Moin, Anselm schrieb: > for(i; "unbekannte bedingung"; i++) kann nicht funktionieren Doch, natuerlich "funktioniert" das. Man darf sich halt nicht wundern. Ist bestimmt wieder dieses boese C dran schuld. Wenn der Bauer nicht schwimmen kann, liegts an der Badehose. SCNR, WK
Anselm schrieb: > for(i; "unbekannte bedingung"; i++) kann nicht funktionieren Das ist keine "unbekannte bedingung" sondern eine "leere bedingung" Und damit gültiges C oder C++. Das funktioniert wie im Grundlagenbuch beschrieben. Bedenke: Die Entscheidung wird im Schleifenkörper getroffen und dieser ggf. mit break verlassen. Also alles im grünen Bereich, vielleicht nicht schön, aber von der Seite her ok.
EAF schrieb: > Das funktioniert wie im Grundlagenbuch beschrieben. Ja, aber vermutlich nicht so wie vom TO beabsichtigt.
EAF schrieb: > Bedenke: > Die Entscheidung wird im Schleifenkörper getroffen und dieser ggf. mit > break verlassen. Oder auch nicht, wie schon oben beschrieben: (prx) A. K. schrieb: > Auch dann noch, wenn der jeweils gewünschte Buchstabe überhaupt nicht > vorkommt? MfG, Arno
Dergute W. schrieb: > Moin, > > Anselm schrieb: >> for(i; "unbekannte bedingung"; i++) kann nicht funktionieren > > Doch, natuerlich "funktioniert" das. Man darf sich halt nicht wundern. > Ist bestimmt wieder dieses boese C dran schuld. Wenn der Bauer nicht > schwimmen kann, liegts an der Badehose. In jeder "normalen" Sprache wird ein FOR ohne Next oder anderweitige Bedingung sofort mit Husten und Spucken des Compilers beantwortet. Weil das Unfaug ist. C an sich ist aber noch größerer Unfug, wenn es solche Konstrukte ohne Murren zuläßt.
Großes Zeh Buch schrieb: > C an sich ist aber noch größerer Unfug, wenn es solche Konstrukte ohne > Murren zuläßt. Du musst die knappe Syntax von C nicht mögen, aber wenn du C nutzt, solltest du die Sprache zumindest kennen. Ein for(;;) als Dauerschleife war von Anfang an ausdrücklich vorgesehen und ist ganz offen dokumentiert.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Du musst die knappe Syntax von C nicht mögen, aber wenn du C nutzt, > solltest du die Sprache zumindest kennen. Ein for(;;) als Dauerschleife > war von Anfang an ausdrücklich vorgesehen und ist ganz offen > dokumentiert. Ich mag nicht nur die knappe Syntax nicht, ich mag C als Ganzes nicht. Deshalb nutze ich es auch nicht, weil ich auf Fußangeln und Stolperfallen gut verzichten kann. In der allergrößten Not würde ich ein While(1) vorziehen.
Großes Zeh Buch schrieb: > Ich mag nicht nur die knappe Syntax nicht, ich mag C als Ganzes nicht Das sei dir unbenommen. Nur warum denkst du dann, dieser Kommentar wäre in irgendeiner Weise nützlich in diesem Thread?
Großes Zeh Buch schrieb: > wenn es solche Konstrukte ohne > Murren zuläßt. Es murrt doch. Muss man aber auch beachten und zulassen.
Das Fehlen der Bedingung im For-Kopf heißt – was würde man auch anderes erwarten – "bedingungslos". Somit läuft die Schleife so lange, bis sie anderweitig (bspw. durch break) abgebrochen wird. Großes Zeh Buch schrieb: > In jeder "normalen" Sprache wird ein FOR ohne Next Next gibt es nur in Basic und verwandten Sprachen. Wenn du nur diese als normale Sprachen ansiehst, ist dein Teller eine Suppenschüssel mit Deckel :) > oder anderweitige Bedingung Next ist keine Bedingung, sondern lediglich die Markierung des Schleifenendes. > sofort mit Husten und Spucken des Compilers beantwortet. Wenn mich der Compiler anhusten oder gar anspucken würde, würde ich aber sofort zurückspucken. Er hat mich gefälligst freundlich auf meine Fehler hinzuweisen ;-)
Yalu X. schrieb: > Das Fehlen der Bedingung im For-Kopf heißt – was würde man auch anderes > erwarten – "bedingungslos". Somit läuft die Schleife so lange, bis sie > anderweitig (bspw. durch break) abgebrochen wird. So ist es. Der Schwachsinn bei C ist halt nur, das ein Konstrukt, was dazu prädestiniert ist, eie abzählbare Anzahl von Iterationen zu liefern, auch mißbraucht werden kann, um eine unbegrenzte Anzahl von Iterationen auszuführen. Das ist nicht sehr logisch, insbesondere nicht unter den Aspekt, dass mit while() ja ein viel besser geeignetes Konstrukt zur Verfügung steht, bei dem man die Intention LESBAR angeben muss. Aber klar, logisch ist C ja sowieso nicht. > Next gibt es nur in Basic und verwandten Sprachen. Wenn du nur diese als > normale Sprachen ansiehst, ist dein Teller eine Suppenschüssel mit > Deckel :) Mein Gott, häng' dich jetzt nicht an konkreten Schlüsselwörtern konkreter Sprachen auf. Die sind doch Wurscht. Es geht um die Intention einer Kontrollstruktur. Und um die Restriktionen, die die verfickte Sprache anwendet, um die intentionsgerechete Verwendung sicher zu stellen. Und da kackt C einfach mal ganz fürchterlich ab.
1 | for( hier sind meine Start-Bedingungen; |
2 | hier sind meine Ende-Bedingungen; |
3 | tue unbedingt dies bei jedem Durchgang ) |
Finde ich persönlich jetzt gar nicht mal so schlecht. Ist aber sicherlich Geschmackssache.
Norbert schrieb: > for( hier sind meine Start-Bedingungen; > hier sind meine Ende-Bedingungen; > tue unbedingt dies bei jedem Durchgang ) > Finde ich persönlich jetzt gar nicht mal so schlecht. > Ist aber sicherlich Geschmackssache. Das ist ja auch die vollkommen normale Verwendung. Darum geht es aber hier nicht.
c-hater schrieb: > insbesondere nicht > unter den Aspekt, dass mit while() ja ein viel besser geeignetes > Konstrukt zur Verfügung steht, Ist das wirklich in diesem Fall auch so? Mir scheint beides nicht so gelungen:
1 | while(1) |
2 | {
|
3 | //hier tu das eine
|
4 | if(bedingung) break; |
5 | //hier tu noch was anderes
|
6 | i++; |
7 | }
|
8 | |
9 | for(;;i++) |
10 | {
|
11 | //hier tu das eine
|
12 | if(bedingung) break; |
13 | //hier tu noch was anderes
|
14 | }
|
Die for Variante spart immerhin ein paar Tastendrücke ein (wenn man denn darauf Wert legt)
Schauspieler-Entdecker schrieb: > Norbert schrieb: >> for( hier sind meine Start-Bedingungen; >> hier sind meine Ende-Bedingungen; >> tue unbedingt dies bei jedem Durchgang ) >> Finde ich persönlich jetzt gar nicht mal so schlecht. >> Ist aber sicherlich Geschmackssache. > > Das ist ja auch die vollkommen normale Verwendung. Darum geht es aber > hier nicht. Hmmm, ist das so?
1 | for (Ich habe keine Start-Bedingungen; |
2 | Ich habe keine Ende-Bedingungen; |
3 | Es gibt hier oben nichts was _unbedingt_ getan werden muss) { |
4 | Mach solange dies hier, |
5 | zumindest bis ich Ende sage… |
6 | }
|
EAF schrieb: > Mir scheint beides nicht so gelungen: > while(1) > { > i++; > } > > for(;;i++) > { > } > Die for Variante spart immerhin ein paar Tastendrücke ein > (wenn man denn darauf Wert legt) Na ja, spätestens wenn irgendwo im Rumpf ein continue an ungünstiger Stelle vorkommt, könnte es sich als nützlich erweisen trotzdem bedingungslos i zu inkrementieren (wenn man es denn will) Ich wäre demnach für Version 2.
Ob diese Empfehlung für Programmierung in einer als geschwätzig bekannten Sprache wohl Gefallen findet? Immerhin kann keinerlei Zweifel aufkommen, was damit gemeint ist:
1 | PERFORM UNTIL 1 < 0 |
2 | DISPLAY "Something" |
3 | END-PERFORM |
https://programming-idioms.org/idiom/50/make-an-infinite-loop/3307/cobol
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ob diese Empfehlung für Programmierung in einer als geschwätzig > bekannten Sprache wohl Gefallen findet? Immerhin kann keinerlei Zweifel > aufkommen, was damit gemeint ist:PERFORM UNTIL 1 < 0 > DISPLAY "Something" > END-PERFORM > https://programming-idioms.org/idiom/50/make-an-infinite-loop/3307/cobol Manche Leute ekeln sich aber auch vor gar nichts! ;-)
Norbert schrieb: > spätestens wenn irgendwo im Rumpf ein continue an ungünstiger > Stelle vorkommt, Guter Einwand.
Mit C, C++ und Java Unzufriedene, einschliesslich des alten Hasens Ken Thompson, haben bei Google eine Sprache "Go" definiert. Und dabei völlig zurecht erkannt, dass for(;;) an sich der richtige Ansatz ist, aber viel zu umständlich:
1 | for { |
2 | ...
|
3 | }
|
Besonders sprechend ist sicherlich Haskell:
1 | let x = x in x |
:
Bearbeitet durch User
(prx) A. K. schrieb: > Und dabei völlig > zurecht erkannt, dass for(;;) an sich der richtige Ansatz ist, aber viel > zu umständlich: [...] Nö. Das ist so ziemlich die schlimmste Perversion, die dieser Kontrollstruktur wiederfahren konnte... Mehr als sinnentleert, vollkommen sinnwidrig.
1 | COMEFROM REPEATME |
2 | … |
3 | … |
4 | … |
5 | LABEL REPEATME |
Besser so? ;-)
c-hater schrieb: > Mehr als sinnentleert, vollkommen sinnwidrig. Fein, dass du dir selber die Deutungshoheit zuteilst. Das klappt aber nur in deinem kleinen Innenweltuniversum.
Norbert schrieb: > Besser so? ;-) Grundsätzlich sind Strukturen/Verfahren mit Goto keine unbedingt schlechte Idee im Parserbau. Wobei ich die Beschränkung auf Vorwärtssprünge empfehlen würde. Das wirkt der Spagettifizierung deutlich entgegen.
Norbert schrieb: > Besser so? ;-) Eindeutig. Aber INTERCAL war als Jux konzipiert. FORTRAN nicht: https://en.wikipedia.org/wiki/COMEFROM#OS/360_Fortran_G
Ach da gibt's so Einiges bei dem ich nicht sicher bin ob's vielleicht doch nur ein fürchterlich missglückter Scherz war. Zum Beispiel als ein paar betrunkene Mauer zusammen saßen und einer sagte ›Halt mal mein Bier‹ Und die anderen meinten: Das traust du dich nicht! Na und mit der PHP-Schweinerei müssen nun alle leben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.