While in C?
0 0 1 0 0 
Der Martin
0 1 Der Martin
0
0 0 Der Martin
0 
Gunnar Bittersmann
0
While in C?
Hey!
Kann man in c while schleifen nur nutzen wenn man bis 0 runterzählen will oder geht das auch mit boolean werten??
Danke, Stefan
-
Hallo,
solange die Bedinung der While Schleife true/wahr ist, läuft diese.P.S. Eine Whileschleife kann man mit break; unterbrechen.
MFG
Andavos -
Kurze Erklärung zur While-Schleife: http://www.thp.uni-duisburg.de/uni_access/pc/node32.html
-
Hallo Stefan,
Kann man in c while schleifen nur nutzen wenn man bis 0 runterzählen will oder geht das auch mit boolean werten??
Es gibt in C keine Bool'sche Datentypen. Alles, was nicht 0 ist, wird als 'true' gewertet (in if(), while(), etc.), alles, was 0 ist, wird als 'false' gewertet.
Bsp:
int i = 1; while (i) { // tu was if (/* abbruchbedingung */) { i = false; } }(ok, das Beispiel ist doof, weil man an dieser Stelle besser
break;verwendet hätte, aber das Prinzip dürfte klar geworden sein, oder?Weiterführende Lektüre: < http://www2.informatik.uni-wuerzburg.de/dclc-faq/kap8.html>
Viele Grüße,
Christian-
Hi,
» »» Kann man in c while schleifen nur nutzen wenn man bis 0 runterzählen will oder geht das auch mit boolean werten??
»»Es gibt in C keine Bool'sche Datentypen.
Aber selbstverständlich gibt es in C einen boolschen Datentypen. Aus ISO/IEC 9899:
7.16 Boolean type and values <stdbool.h>
1 The header <stdbool.h> defines four macros.
2 The macro bool expands to _Bool.
3 The remaining three macros are suitable for use in #if preprocessing directives. They are
true
which expands to the integer constant 1,
false
which expands to the integer constant 0, and
__bool_true_false_are_defined
which expands to the decimal constant 1.Aufgrund des folgenden Absatzes:
4 Notwithstanding the provisions of 7.1.3, a program is permitted to undefine and perhaps then redefine the macros bool, true,and false.
folgt, das das hier ...
Alles, was nicht 0 ist, wird als 'true' gewertet (in if(), while(), etc.), alles, was 0 ist,
wird als 'false' gewertet.
... korrekt ist, jedoch das Beispiel, auch wenn es nicht wirklich falsch ist doch zumindest Kopfschmerzen aufgrund von Unvollständigkeit verursacht. Bei Code für die Produktion sollten die Werte von false und true an einer Stelle geprüft und/oder definiert werden, auf die man exklusiven Einfluß hat.
(ok, das Beispiel ist doof, weil man an dieser Stelle besser
break;verwendet hätte,Warum, in Edsger Dijkstras Namen? >;->
Weiterführende Lektüre http://www2.informatik.uni-wuerzburg.de/dclc-faq/kap8.html
Ja, auch die neueste Version hat das noch drin, obwohl bereits seit 6 Jahren veraltet. Man könnte fast meinen, das Steve das mit Absicht machte ;-)
so short
Christoph Zurnieden
-
Hallo Christoph,
ich bin mir ja nicht ganz sicher, aber glaube, du versuchst uns einen Bären aufzubinden.
Aber selbstverständlich gibt es in C einen boolschen Datentypen. Aus ISO/IEC 9899: [...]
Ich behaupte: Nein.
Nur dadurch, dass die Konstanten true und false definiert werden, existiert noch lange kein eigenständiger Datentyp. Es gibt logische Operatoren (&&, ||, !), die Teilausdrücke als boolsche Werte interpretieren und ein dementsprechendes Ergebnis zurückliefern. Aber letztendlich geht das alles auf den Basistyp int zurück.Erst C++ hat einen eigenen boolschen Datentyp.
... sollten die Werte von false und true an einer Stelle geprüft und/oder definiert werden, auf die man exklusiven Einfluß hat.
... oder stattdessen gleich die Werte 0 und 1 eingesetzt werden. Bei direkten Zuweisungen finde ich das genauso gut wie die Konstanten true oder false, und bei Berechnungen oder Vergleichsoperationen braucht man die Konstanten eh nicht, sie machen nur die Formulierung umständlicher.
Mich schüttelt's immer, wenn ich Ausdrücke lese wie z.B.
if ( (u>0)==true && errorflag==false) ...Warum schreibt man da nicht einfach und klar
if ( u>0 && !errorflag) ...
Das ist kürzer, leicher lesbar, und sogar effizienter, wenn der Compiler den Code nicht sowieso schon optimiert.Schönes Wochenende erstmal,
Martin
-
Hi,
Aber selbstverständlich gibt es in C einen boolschen Datentypen. Aus ISO/IEC 9899: [...]
Ich behaupte: Nein.
ISO/IEC 9899 (+ die beiden Corr. natürlich.) ist der aktuelle C-Standard. Den kleinen Absatz, der den boolschen Datentyp _Bool definiert habe ich hier zitiert.
Und wenn Du Dich auf den Kopf stellst und stur das Gegenteil behauptest: es ist Standard. Es ist sogar _internationaler_ Standard im Gegensatz zum ANSI, der nur lokaler amerikanischer Standard ist. Wie der Name, nein: die Namen ja schon sagen.Andererseits ist es natürlich etwas unfair von mir einen Standard zu zitieren, der über 200EUR in der Anschaffung kostet. Ich bitte herzlichst um Entschuldigung, aber es ging hier einfach nicht anders. Die nächstgelegene Universität mit IT-Abteilung sollte aber einen zur Einsicht rumliegen haben.
Mich schüttelt's immer, wenn ich Ausdrücke lese wie z.B.
if ( (u>0)==true && errorflag==false) ...Warum schreibt man da nicht einfach und klar
if ( u>0 && !errorflag) ...
Das ist kürzer, leicher lesbar,Ja, das ist es, jedoch ...
und sogar effizienter, wenn der Compiler den Code nicht sowieso schon optimiert.
... da beides _haargenau_ das Gleiche bedeutet, ist da nix zum optimieren. Höchstens zu versauen.
Schönes Wochenende erstmal,
Das dauert leider noch *sigh*
so short
Christoph Zurnieden
-
Hallo,
Ich behaupte: Nein.
ISO/IEC 9899 (+ die beiden Corr. natürlich.) ist der aktuelle C-Standard. Den kleinen Absatz, der den boolschen Datentyp _Bool definiert habe ich hier zitiert.
Standard hin oder her: Was du zitiert hast (nämlich die Definition einiger Makros), definiert noch keinen Datentyp. Das Wichtigste hast du nämlich unterschlagen:
typedef enum {
false = 0,
true = 1
} _Bool;
Hättest du die paar Zeilen in deinem ersten Posting abgebildet, dann wäre ich _sofort_ einverstanden gewesen. Das _ist_ ein eigener Datentyp (der aber zum Glück zuweisungskompatibel zu int ist).Andererseits ist es natürlich etwas unfair von mir einen Standard zu zitieren, der über 200EUR in der Anschaffung kostet.
Stimmt, das ist tatsächlich unfair. ;)
Die nächstgelegene Universität mit IT-Abteilung sollte aber einen zur Einsicht rumliegen haben.
Mag sein. Aber das ist mir jetzt zuviel Aufstand.
... da beides _haargenau_ das Gleiche bedeutet, ist da nix zum optimieren. Höchstens zu versauen.
Nein, es ist nicht dasselbe. Der erste Teilausdruck im ersten Beispiel ((u>0)==true) enthält nämlich genaugenommen schon zwei Vergleichsoperationen: Vergleiche das Ergebnis des Vergleichs (u>0) mit der Konstanten true (=1). Die zweite Hälfte, nämlich der Vergleich mit der Konstanten, ist überflüssig und würde dasselbe Ergebnis hervorbringen wie schon der Teilausdruck (u>0). Deshalb wird sowas von vielen Compilern gleich wegoptimiert.
Schönes Wochenende erstmal,
Das dauert leider noch *sigh*Ohje, mein Beileid. ;)
Martin
-
Hi,
Standard hin oder her: Was du zitiert hast (nämlich die Definition einiger Makros), definiert noch keinen Datentyp.
Das ist die Definition des Datentypes _Bool. Der ist, genauso wie _Imaginary und _Complex neu in ISO-9899 von 1999.
Das Wichtigste hast du nämlich unterschlagen:
typedef enum {
false = 0,
true = 1
} _Bool;Das finde ich aber nirgendwo im Standard. Wo hast Du das her?
»»as _ist_ ein eigener Datentyp (der aber zum Glück zuweisungskompatibel zu int ist).
Ja, das ist der Datentyp "enum" mit dem Namen "_Bool". Was hat das mit dem boolschen Datentyp _Bool aus ISO-9899 zu tun? Außer dem Namen?
[Kosten für ISO-Standards]
Stimmt, das ist tatsächlich unfair. ;)
Ja, etwas. Aber besser so als das irgendwelche Firmen das bezahlen. Man weiß ja, was dann dabei rauskommt.
Die nächstgelegene Universität mit IT-Abteilung sollte aber einen zur Einsicht rumliegen haben.
Mag sein. Aber das ist mir jetzt zuviel Aufstand.Kann ich mir vorstellen, aber mir war es wirklich unangenehm konnte nur keine Alternative finden. Es ist aber so zumindest ohne große Kosten (je nachdem, wo Du wohnst natürlich, aber auf über 200 EUR Fahrtkosten bis zu nächsten Uni zu kommen schafft man normalerweise nur mit dem Taxi ;-) nachprüfbar ob ich korrekt zitiere.
Nein, es ist nicht dasselbe. Der erste Teilausdruck im ersten Beispiel ((u>0)==true) enthält nämlich genaugenommen schon zwei Vergleichsoperationen:
Das sind sogar drei Vergleichsoperationen.
(u>0)
(u>0)==true
((u>0)==true)Deshalb wird sowas von vielen Compilern gleich wegoptimiert.
Ja, das ist ganz strenggenommen eine Optimierung, da hast Du natürlich Recht.
Schönes Wochenende erstmal,
Das dauert leider noch *sigh*Ohje, mein Beileid. ;)
Ja, grins Du nur! Schadenfreude ist doch immer wieder die schönste Freude, was? ;-)
so short
Christoph Zurnieden
-
Moin!
Das ist die Definition des Datentypes _Bool. Der ist, genauso wie _Imaginary und _Complex neu in ISO-9899 von 1999.
Es ist nur ein winziger Teil davon.
Zur Definition eines Datentyps gehört aber IMHO auch das "Wissen" des Compilers, wie er mit diesem Datentyp umzugehen hat. Also z.B. die Implementierung von Operatoren, ggf. Funktionen im Bezug auf diesen neuen Datentyp. In C++ kann man das etwa durch Überladen von Operatoren auf Quelltextebene machen; in reinem C muss die Implementierung zumindest der Operatoren fest im Compiler verankert sein.
Deshalb sagte ich, die Definition einiger Konstanten reicht noch nicht, um einen neuen Datentyp (mit eigenen Eigenschaften) zu definieren.Das Wichtigste hast du nämlich unterschlagen:
typedef enum ...Das finde ich aber nirgendwo im Standard. Wo hast Du das her?
Ich habe einfach Google nach stdbool.h gefragt (http://www.google.de/search?num=10&as_q=stdbool.h). Das dritte Suchergebnis hat mich zu einer kompletten stdbool.h geführt: http://mirror.sg.depaul.edu/pub/OpenBSD/src/include/stdbool.h
Ja, das ist der Datentyp "enum" mit dem Namen "_Bool". Was hat das mit dem boolschen Datentyp _Bool aus ISO-9899 zu tun? Außer dem Namen?
Das _ist _ er, hätte ich gedacht...
[Kosten für ISO-Standards]
Stimmt, das ist tatsächlich unfair. ;)
Ja, etwas. Aber besser so als das irgendwelche Firmen das bezahlen. Man weiß ja, was dann dabei rauskommt.
Naja, hier ist es noch akzeptabel, weil die IT-Standards idR keine rechtsverbindlichen Vorschriften sind. Aber ich habe beruflich mit der Prüfung von Produkten auf CE-Konformität zu tun, und die in diesem Bereich geltenden Normen _sind_ rechtsverbindliche Vorschriften, bei deren Missachtung im Einzelfall sogar empfindliche Strafen drohen können. Und hier finde ich es nicht in Ordnung, dass die Normungsgremien viel Geld für ihre Werke verlangen, die aber jeder einzuhalten hat.
Wenn ich den Führerschein mache, muss ich ja auch keine 120 Euro bezahlen, um mal die STVO lesen zu dürfen. Die ist öffentlich, und so sollte es mit anderen Normen und Vorschriften auch sein, wenn sie direkt oder indirekt Gesetzescharakter haben.
Dass die Ausarbeitung von Standards viel Arbeit macht und Geld kostet, ist mir andererseits schon klar.Ja, grins Du nur! Schadenfreude ist doch immer wieder die schönste Freude, was? ;-)
Zumindest die ehrlichste...
Jetzt aber!Martin
-
Hi,
Das ist die Definition des Datentypes _Bool. Der ist, genauso wie _Imaginary und _Complex neu in ISO-9899 von 1999.
Es ist nur ein winziger Teil davon.
Zur Definition eines Datentyps gehört aber IMHO auch das "Wissen" des Compilers, wie er mit diesem Datentyp umzugehen hat.Ist in den gängigen Compilern drin, dies Bedingung ist also auch erfüllt. Was brauchst Du noch, das es Dir schmeckt?
Also z.B. die Implementierung von Operatoren, ggf. Funktionen im Bezug auf diesen neuen Datentyp.
Alles was früher pseudo-bool war ist jetzt korrekt bool. Aufgrund von Abwärtskompatibilität ist die Definition jedoch so gewählt worden, das die alten Funktionen noch funktionieren.
In C++ [...]
Wir reden über C, das ist trotz aller Gemeinsamkeiten eine komplett andere Sprache.
Deshalb sagte ich, die Definition einiger Konstanten reicht noch nicht, um einen neuen Datentyp (mit eigenen Eigenschaften) zu definieren.
Nur weil es irgendwo nicht so eingebaut ist, wie Du es gerne haben möchtest ist es noch lange nicht falsch.
Das Wichtigste hast du nämlich unterschlagen:
typedef enum ...
Das finde ich aber nirgendwo im Standard. Wo hast Du das her?Ich habe einfach Google nach stdbool.h gefragt
Das ist die Implementation, um genau zu sein die von OpenBSD. Der GCC (3.4.1 habe ich gerade zur Hand) definiert das z.B. als Macros:
#define bool _Bool
#define true 1
#define false 0
[...]
#define __bool_true_false_are_defined 1Aber was hat das mit dem Standard zu tun? Hauptsache ist, was hinten rauskommt, der Weg dahin ist jedoch vollkommen schnurz.
[Kosten für ISO-Standards]
Stimmt, das ist tatsächlich unfair. ;)
Ja, etwas. Aber besser so als das irgendwelche Firmen das bezahlen. Man weiß ja, was dann dabei rauskommt.
Naja, hier ist es noch akzeptabel, weil die IT-Standards idR keine rechtsverbindlichen Vorschriften sind.
Die ISO Standards sind es eigentlich schon, Deutschland hat da auch unterschrieben. Aber die Betonung liegt hier auf "eigentlich", da hast Du natürlich leider Recht.
Und hier finde ich es nicht in Ordnung, dass die Normungsgremien viel Geld für ihre Werke verlangen, die aber jeder einzuhalten hat.
Naja, die kann man wenigstens von der Steuer absetzen ;-)
(Konnte ich mit dem C-Standard aber auch, wenn auch etwas unwillig. Sonst hätte ich ihn auch nicht erworben, ich baue keine C-Compiler. Zumindest nicht regelmäßig)so short
Christoph Zurnieden
-
-
-
-
-
Aber selbstverständlich gibt es in C einen boolschen Datentypen. Aus ISO/IEC 9899: [...]
Ich behaupte: Nein.
Nur dadurch, dass die Konstanten true und false definiert werden, existiert noch lange kein eigenständiger Datentyp.Nein. Aber durch die Definition im Standard. Wie dieser Datentyp implementiert wird ist völlig irrelevant, wichtig ist nur, was der Standard dazu sagt. Und wenn der sagt "es gibt einen boolschen Datentyp", dann gibt es ihn. Wie der letztenendes im Compiler implementiert ist, ist dabei nicht wichtig.
-
Hallo,
Nur dadurch, dass die Konstanten true und false definiert werden, existiert noch lange kein eigenständiger Datentyp.
Nein. Aber durch die Definition im Standard. Wie dieser Datentyp implementiert wird ist völlig irrelevant, wichtig ist nur, was der Standard dazu sagt. Und wenn der sagt "es gibt einen boolschen Datentyp", dann gibt es ihn.
Das hat Christoph mir auch schon beizubringen versucht, und es ist ja auch korrekt. Nur bin ich es gewöhnt, die Dinge eher von der praktischen Seite zu sehen. Wenn ihr sagt, der Datentyp _Bool sei im aktuellen Standard definiert, dann ist das fein, aber es ist erst einmal nur Theorie.
Wie der letztenendes im Compiler implementiert ist, ist dabei nicht wichtig.
Doch, das ist aus meiner Sicht das einzig entscheidende. Denn was nützt mir ein Standard, wenn meine Hardware, meine Software, mein Compiler ihn nicht unterstützt? In HTML/CSS sind auch jede Menge Raffinessen im Standard definiert, aber in kaum einem Browser implementiert. Also was hilft's? Für uns Anwender (Programmierer, Webdeveloper) ist entscheidend, was unsere Arbeits- und Hilfsmittel tatsächlich können. Dass sich die Hersteller dieser Arbeits- und Hilfsmittel bei Weiterentwicklungen an aktuelle Standards halten, setze ich voraus (trifft aber leider auch nicht immer zu).
Deswegen hab ich bei meinen vorherigen Postings zum Thema Boolscher Datentyp auch immer so auf der Implementierung beharrt.Abgesehen davon benutze ich auch heute noch einen C-Compiler, der mittlerweile rund 10 Jahre alt ist (Borland C++ 5.02). Und ich möchte den gegen keinen anderen eintauschen, den ich in der Zwischenzeit kennengelernt habe. Und nein, BC5 kennt natürlich keinen Datentyp _Bool oder bool; ich halte den auch für völlig überflüssig. Ich selbst denke so maschinennah, dass ich den Unterschied für unbedeutend halte.
Und bevor mir jetzt wieder ein Musterprogrammierer ins Wort fällt: Selbstverständlich kenne und beachte ich den Unterschied in der Bedeutung. Aber in der Realisierung auf Maschinenebene sind die meisten elementaren Datentypen trotzdem ein und dasselbe. Sie auseinanderzuhalten möchte ich der Disziplin des Programmierers überlassen (der hoffentlich weiß, was er tut), nicht einer Typprüfung durch den Compiler. Ich krieg schon jedesmal "so'n Hals", wenn sich mein Compiler mal wieder beklagt "Warning: Mixing pointers to signed and unsigned char". Herrje, das weiß ich, und wenn ich das mache, dann mit Absicht. ;)So long,
Martin
-
Wenn ihr sagt, der Datentyp _Bool sei im aktuellen Standard definiert, dann ist das fein, aber es ist erst einmal nur Theorie.
Nein, Fakt :)
Wie der letztenendes im Compiler implementiert ist, ist dabei nicht wichtig.
Doch, das ist aus meiner Sicht das einzig entscheidende. Denn was nützt mir ein Standard, wenn meine Hardware, meine Software, mein Compiler ihn nicht unterstützt?
Gegenfrage: seit wann bestimmt eine Implementation, ob etwas richtig oder falsch ist oder ob etwas existiert oder nicht?
[...]
Die Frage, ob der Datentyp sinnvoll ist oder ob er benutzt werden sollte, stand überhaupt nicht zur Debatte.
Deswegen hab ich bei meinen vorherigen Postings zum Thema Boolscher Datentyp auch immer so auf der Implementierung beharrt.
Die Implementierung bestimmt nicht die Existenz. Da spricht man von Unterstützung.
Abgesehen davon benutze ich auch heute noch einen C-Compiler, der mittlerweile rund 10 Jahre alt ist (Borland C++ 5.02).
Das ist kein C-Compiler :)
Und ich möchte den gegen keinen anderen eintauschen, den ich in der Zwischenzeit kennengelernt habe. Und nein, BC5 kennt natürlich keinen Datentyp _Bool oder bool; [...]
Er ist auch kein C-Compiler.
-
Wenn ihr sagt, der Datentyp _Bool sei im aktuellen Standard definiert, dann ist das fein, aber es ist erst einmal nur Theorie.
Nein, Fakt :)Ach ja? Wenn sich ein Team von Ingenieuren und Designern bei Mercedes endlich über das Konzept für eine neue PKW-Baureihe geeinigt haben dann _existiert_ dieses Modell noch lange nicht. Es ist -um bei der aktuellen Nomenklatur zu bleiben- definiert, aber noch nicht implementiert, existiert also noch nicht.
Gegenfrage: seit wann bestimmt eine Implementation, ob etwas richtig oder falsch ist oder ob etwas existiert oder nicht?
Ob etwas richtig oder falsch ist, das bestimmt schon der zugrundeliegende Standard (wenn es einen gibt).
Die Existenz definiert sich nach _meiner_ Ansicht aber ausschließlich dadurch, dass ein bestimmtes Merkmal oder Produkt auch in der Praxis umgesetzt ist. Existenz bedeutet Realität, Realität bedeutet technische Umsetzung in die Praxis.Abgesehen davon benutze ich auch heute noch einen C-Compiler, der mittlerweile rund 10 Jahre alt ist (Borland C++ 5.02).
Das ist kein C-Compiler :)
Stimmt, es ist mehr als das.
Es ist eine komplette Entwicklungsumgebung mit Compiler, Debugger, und einer Menge Zusatztools.
Für die PC/Windows-Plattform eine der besten, die ich kenne. Wenn du BC5 nicht magst, ist das deine Sache. Ich werde nicht versuchen, dich zu bekehren, bleibe aber selbst auch bei meiner Überzeugung. ;)Ciao,
Martin
-
-
-
-
-
-
-
Stefan,
Kann man in c while schleifen nur nutzen wenn man bis 0 runterzählen will
Was genau willst du eigentlich?
Zum Runterzählen bis 0 ist die for-Schleife beste Wahl.
Die while-Schleife bietet sich an, wenn du beim Eintritt in die Schleife noch nicht weißt, wie oft die Schleife durchlaufen werden wird.
Gunnar
--
“I got my finger on the trigger / But I don’t know who to trust” (Bruce Springsteen, Devils and Dust) -
Hallo,
aaaaha! solangsam verstehe ich _vielleicht_ was Du meinst, hehe ;-)
Du kannst auch z.B. bis 1 runterzählen:
i=10;
while(i>1)
{
i--;
}entscheidend ist, ob der _Ausdruck_ in der while-Klammer true ergibt oder eben nicht. Ein Bekannter von mir schrieb immer gern while(true). Der war aber auch so gut, daß er nie eine korrekte Abbruchbedingung innerhalb der Schleife vergaß.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch