Hallo,
ich hoffe das passt hier hin.
Ich habe Probleme mit dieser Aufgabe:
int a = 5;
int b = 7;
int c = 11;
Sind die Wahrheitswerte Variablenwerte wahr oder falsch?
a) (a<=5) && (b>7)
b) ((a<5) && (b>7)) || (a<b) || (b>9)
c)!(!(a<=5) && ! (b>7))
d) (c=1) || (b>9) || (a<-3)
a) falsch
b) wahr
c) kann ich nicht lösen
d) c=1 bereitet mir Probleme
Kann mir jemand bitte helfen?
a) und b) sind richtig gelöst.
Warum kannst du d) nicht lösen? Wo liegt das Problem?
Zu d): Was bedeutet "c=1"? Kann das auch innerhalb eines Ausdrucks als
Teilausdruck verwendet werden? Wenn ja, was ist dessen Wert?
Wenn du diese Fragen nicht beantworten kannst: Dein C-Buch kann es ganz
sicher :)
b soll laut prof falsch sein, ich habe aber wahr.
zu d) c = 1, die 1 steht für wahr, stimmt ja :D,also ist der ausdruck
richtig
bei der c stören mich die !
hallo
um es kurz zu machen zu
c: da reicht es schon fast den Ausdruck (a<=5) an zu schauen. Der ist
true da a==5.
Das wird dann mit ! negiert. Daraus ergibt sich schon, dass die &&
Verknüpfung auch false sein muss.
Da am Schluss alles auch negiert wird, kommt wieder true raus.
Das ist beim durchlesen eher verwirrend :)
Also noch mal
(a<=5) ist true -> !true = false -> false && ... = false -> !false =
true.
hoffentlich war das besser :)
zum d)
c=1 ist eine Zuweisung und kein Vergleich. Das ist grade in if
Konstrukten ein beliebter Anfängerfehler.
c=1 gibt 1 und somit ein logisch true zurück. Da alle andern Bedingungen
verodert sind, kommt ein true auch für alles raus.
Grüße,
Leyla S. schrieb:> b soll laut prof falsch sein, ich habe aber wahr.
Entweder hat sich der Prof vertan, oder du hast die Aufgabe falsch
abgeschrieben. Da a<b wahr ist, ist es auch dessen Oder-Verknüpfung mit
beliebigen anderen Operanden.
> bei der c stören mich die !
Nach dem Beitrag von nicht"Gast" weißt du hoffentlich, was das '!'
bedeutet, nämlich ein logisches "Nicht" :)
Okey vielen Dank :). Ja, das mit der Negation habe ich jetzt verstanden.
((a<=5) && (b>7)) !=0 || (c >= a*b)
((wahr) && (falsch)) !=0 || (falsch)
In meinem Buch steht, das ! die stärkste Bindung ist. Also muss ich mir
jetzt diesen Teil ansehen ! = 0, 0 steht für falsch, also kommt hier
wahr raus.
((wahr) && (falsch)) wahr || (falsch)
(falsch) wahr || falsch
Was mache ich hier falsch
Okey danke, habe eben in meinem Buch nachgesehen
!= steht für ungleich
((wahr) && (falsch)) !=0 || (falsch)
Ungleich 0 bedeutet, dann dass es wahr ist?
Leyla S. schrieb:> Dann wäre das 0 aber =0.
Den Satz habe ich nicht verstanden.
> falsch || falsch = falsch
Das ist richtig und die Lösung der Aufgabe.
Leyla S. schrieb:> Also ich meinte damit nur, dass der Integerwert 0 ist. Dann würde da ja> stehen 0!=0 und das ist falsch.
Ok, dann hast du's verstanden :)
Noch ein genereller Tipp:
Boolesche Werte sind in C in Wirklichkeit Zahlen. "falsch" entspricht
dabei dem Wert 0 und "wahr" dem Wert 1. Die Operationen &&, ||, !, <,
<=, ==, !=, >= und > liefern als Ergebnis immer den Integer-Wert 0 oder
1.
Für die Operanden dieser Operationen gilt: 0 zählt als "falsch" alle von
0 verschiedenen Zahlen als "true".
Es gibt in C zwar den Datentyp "bool". Das ist aber genau genommen auch
nur ein numerischer Datentyp, dessen Wertebereich auf 0 und 1
eingeschränkt ist. Es gibt in C auch die Konstanten "false" und "true".
Diese sind aber ebenfalls nur Symbole für die Zahlen 0 und 1.
Wenn einer Variablen vom Typ bool eine von 0 und 1 verschiedene Zahl
zugeweisen wird, wird diese automatisch in eine 1 umgewandelt.
Wenn du also diesen Ausdruck
1
((a<=5)&&(b>7))!=0||(c>=a*b)
analysierst, solltest du das folgendermaßen tun:
1
((a<=5)&&(b>7))!=0||(c>=a*b)
2
((5<=5)&&(7>7))!=0||(11>=5*7)
3
((5<=5)&&(7>7))!=0||(11>=35)
4
((1)&&(0))!=0||(0)
5
(0)!=0||(0)
6
0||(0)
7
0
Dass das so günstiger ist, wirst du merken, wenn euer Prof demnächst
vielleicht mit folgenden (etwas fiesen) Aufgaben kommt:
1
inta=5;
2
intb=true;
3
4
intx=(a>4)+3*(b<10)
oder
1
boola=-5;
2
boolb=true;
3
4
boolx1=(a==-5);
5
boolx2=(a>b);
6
boolx3=(a<b);
7
boolx4=(a-b==false);
Welche Werte haben x, x1, x2, x3 und x4?
Anmerkung: Es ist zwar korrekt, aber überhaupt nicht ratsam, Audrücke
wie in diesen beiden Aufgaben in realen C-Programmen zu schreiben. Sie
dienen nur dazu, das Verständnis der Logikoperationen in C zu festigen.
>d) c=1 bereitet mir Probleme
das ist eine "Falle", die mir als Pascal Programmierer, wenn ich mal was
in C Programmiere) auch immer auf den "Kopf" fällt..
ich MÖCHTE sowas eigentlich nicht, deshalb sollte es für Programmierer
die das nicht wollen, vom Compiler eine (pro Datei) einschaltbare
Warnung/Fehler geben (gibt es sowas??)
(C=1) liefert als "Ergebnis" die Zahl 1, was in C (immer) True ist
(alles was nicht 0 ist ist TRUE)
Yalu X. schrieb:> Es ist zwar korrekt, aber überhaupt nicht ratsam,
Warum nicht? Ich verwende oft Ausdrücke wie:
bool is_bigger = komplexes_statement > komplexes_statement2;
foo(is_bigger);
bar
if (is_bigger)...
Ich finde, man muß da unterscheiden. Das hier:
Yalu X. schrieb:> int x = (a > 4) + 3 * (b < 10)> bool x4 = (a - b == false);
würde ich definitiv nicht empfehlen, während diese Varianten:
Yalu X. schrieb:> bool x1 = (a == -5);> bool x2 = (a > b);> bool x3 = (a < b);
meines Erachtens ok sind, wenn man eben genau das braucht. Ich finde es
dann irgendwie albern, das auseinanderzuziehen zu sowas wie:
1
boolx3;
2
if(a<b)
3
{
4
x3=true;
5
}
6
else
7
{
8
x3=false;
9
}
Das ist nur viel länger, aber kein bischen lesbarer.
Danke für den Tipp.
Zu deiner Aufgabe:
x=4 (wenn es bool wäre, dann wäre es eine 1, aber was mache ich hier?)
x = (a>4) + 3(b<10)
x = 1 + 3*1
x1 = 1
x2 = 0
x3 = 1
x4 = 0
Leyla S. schrieb:> Danke für den Tipp.> Zu deiner Aufgabe:>> x=4 (wenn es bool wäre, dann wäre es eine 1, aber was mache ich hier?)> x = (a>4) + 3(b<10)> x = 1 + 3*1
Nichts. 4 ist schon korrekt.
Du kannst mit dieser 4 zum Beispiel wieder weiterrechnen.
Erst dann, wenn dieses x in einem Zusammenhang benutzt wird, in dem es
als boolscher Wert aufgefasst werden muss, kommt die C Regel zum tragen:
0 gilt als logisch false, alles ungleich 0 gilt als logisch true
Schreibst du zb
1
if(x)
2
machwas
3
else
4
machwasanderes
dann kommt der Zweig 'mach was' zum Zug. Denn 4 ist ja ungleich 0 und
gilt damit als logisch true.
Zwischen int und boolschen Werten in C kann hemmungslos hin und her
gewandelt werden.
Wenn aus einem int ein boolscher Wert gemacht werden muss
* 0 gilt als logisch false
* alles ungleich 0 gilt als logisch true
Wenn aus einem boolschen Wert ein int gemacht werden muss
* logisch false wird zu 0
* logisch true wird zu 1
Und ganz, ganz, ganz wichtig. In C ist fast alles ein Ausdruck, der in
irgendeiner Form mit einem Wert hochkommt.
Auch eine Zuweisung! Der Wert einer Zuweisung ist der zugewiesene Wert.
Genau deshalb kann man ja schreiben
1
i=j=5;
Oder auch
1
if((i=5)>5)
da ist nichts geheimnisvolles dabei. i = 5 ist genauso ein
arithmetischer Ausdruck wie 2 + 3, auch wenn das auf den ersten Blick
verwirren mag. Beide arithmetischen Ausdrücke liefern ein Ergebnis, mit
dem man weiterrechnen kann. Zufällig liefern beide Ausdrücke das
Ergebnis 5. D.h. das Ergebnis von 2 + 3 + ( i = 5 ) ist eine glatte 10.
Aber auch Vergleiche sind nichts anderes als AUsdrücke, die berechnet
werden.
1
i<8
ist ein Ausdruck der ein Ergebnis liefert. true oder false (oder eben 1
oder 0). Auch hier wieder: Das unterscheidet sich in nichts von 2 + 3,
was ebenfalls ein Ausdruck ist, der ein Ergebnis liefert mit dem weiter
gerechnet werden kann.
Ein if hingegen, verlangt innerhalb der Klammer keinen Vergleich. Ein if
verlangt einfach nur
1
if( Ausdruck )
einen Ausdruck, dessen Wert es berechnet. Ist dieser Wert ein logisches
true, gegebenenfalls auch erst nachdem ein int zu einem boolschen Wert
umgeformt wurde), dann wird der then Zweig genommen, ansonsten der else
Zweig.
Wichtig: Da steht 'Ausdruck'. Das muss kein Vergleich sein. Ein
Vergleich ist zwar auch ein Ausdruck aber nicht jeder Ausdruck ist ein
Vergleich!
2 + 3 wäre zb so ein Ausdruck.
Es ist daher völlig legal, das hier zu schreiben
1
if(2+3)
2+3 wird bewertet, das Ergebnis ist 5, 5 ist ungleich 0 und gilt damit
als logisch true -> der then-Zweig vom if wird genommen.
Bitte einen Namen eingeben (nicht "Gast") oder ein schrieb:
> Warum nicht? Ich verwende oft Ausdrücke wie:>> bool is_bigger = komplexes_statement > komplexes_statement2;Rolf Magnus schrieb:> während diese Varianten:>> Yalu X. schrieb:>> bool x1 = (a == -5);>> bool x2 = (a > b);>> bool x3 = (a < b);>> meines Erachtens ok sind, wenn man eben genau das braucht.
Man beachte, dass a und b in diesem Beispiel beide vom Typ bool sind.
Yalu X. schrieb:> Man beachte, dass a und b in diesem Beispiel beide vom Typ bool sind
Ah richtig. Da ist dein Posting etwas verwirrend, weil direkt darüber
schon mal Variablen mit den gleichen Namen aber anderem Typ definiert
wurden. Dann stimme ich dir zu.
Generell sehe ich keinen Grund, bool überhaupt mit Vergleichsoperatoren
zu nutzen, und wenn, dann höchstens mit == und !=. Für alle anderen
gibt's bei bool keinen sinnvollen Grund. Auch arithmetische Operationen
mit bool sind zu vermeiden.
Leyla S. schrieb:> x=4 (wenn es bool wäre, dann wäre es eine 1, aber was mache ich hier?)> x = (a>4) + 3(b<10)> x = 1 + 3*1
Richtig (da hat ja auch Karl Heinz ein paar Erläuterungen dazu
geschrieben).
> x1 = 1> x2 = 0> x3 = 1> x4 = 0
x2 ist richtig, aber vermutlich auch nur durch Zufall.
Ich glaube, du hast – wie auch schon andere – einfach nur übersehen,
dass in diesem zweiten Beispiel a und b nicht mehr vom Typ int, sondern
bool sind (sonst wären deine Ergebnisse nämlich alle korrekt). Und wie
schon oben geschrieben, nehmen bool-Variablen nur die Werte 0 oder 1 an.
Rolf Magnus schrieb:> Da ist dein Posting etwas verwirrend, weil direkt darüber> schon mal Variablen mit den gleichen Namen aber anderem Typ definiert> wurden.
Ja, da hätte ich wohl besser neue Variablennamen verwenden sollen.
> Generell sehe ich keinen Grund, bool überhaupt mit Vergleichsoperatoren> zu nutzen, und wenn, dann höchstens mit == und !=. Für alle anderen> gibt's bei bool keinen sinnvollen Grund. Auch arithmetische Operationen> mit bool sind zu vermeiden.
Genau das wollte ich mit obiger Anmerkung aussagen. Danke, dass du es
noch einmal etwas konkreter formuliert hat.
Robert L. schrieb:> Man beachte, dass es in C überhaupt kein bool gibt..
Seit dem Standard von 1999 schon. Allerding ist bool kein Schlüsselwort,
da dies zu Problemen mit älteren C-Programmen, die selber einen Typ bool
deklarieren, führen würde. Das entsprechende Schlüsselwort in C99 und
C11 heißt stattdessen _Bool, und bool ist ein #define oder typedef im
Header-File stdbool.h, das ebenfalls im Standard beschrieben ist.
Robert L. schrieb:>>Seit dem Standard von 1999 schon>> aber kein "echter" Bool>> soweit ich das verstanden habe:> z.b.>> http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/EXTERNAL_HEADERS/stdbool.h>> ist in C99 aber immer noch sowas möglich:>> _Bool x = 1;
Ja, das ist möglich. Ein int läßt sich implizit nach _Bool konvertieren.
Aber warum sollte es deshalb kein echter Bool sein? Wann ist für dich
ein Boole'scher Typ "echt"?
>Boole'scher Typ "echt"?
siehe Pascal dort gibt's Boolean
kann nur true/false sein
kann man nicht addieren/subtrahieren/größer/kleiner/Zahlen zuweisen usw.
also den ganzen "Blödsinn" nicht machen..
mach mal in C99:
_Bool x = true;
x = x + 1;
if (x) {...}
if (x == true) {...}
Wie ich weiter oben schon schrieb, sind Bools in C eigentlich Zahlen mit
auf 0 und 1 eingeschränktem Wertebereich. Sie stellen aber einen eigenen
Datentyp dar, den es in C90 noch nicht gab.
Was man jetzt als "echt" und "unecht" bezeichnet, ist eine Frage der
Definition.
Klar, eine strengere Typprüfung in booleschen Ausdrücken wäre manchmal
wünschenswert, aber das ist dann eher eine Frage des Typsystems als des
konkreten Datentyps bool. Die Typprüfung in C ist halt generell
höchstens "mittelstreng". char und enum sind ähnlich geartete Fälle.
Robert L. schrieb:> siehe Pascal dort gibt's Boolean>> kann nur true/false sein> kann man nicht addieren/subtrahieren/größer/kleiner/Zahlen zuweisen usw.
Addieren beliebiger Zahlen geht nicht, aber inkrementieren und
dekrementieren schon. Auch der Vergleich mit < und > ist möglich.
Da boolean ein Ordinaldatentyp ist, sind diese Operation durchaus
konsequent, auch wenn man sie so gut wie nie benötigt.
Der Hauptunterschied zu C liegt hier darin, dass Pascal zur Laufzeit ein
Unter- oder Überschreiten des Wertebereichs prüft.
Während in C die wenig sinnvollen Operationen
1
boolvar=true+1;
und
1
boolvar=false-1;
beidesmal boolvar = 1 ergeben, führen die entsprechenden Anweisungen in
Pascal
1
boolvar:=succ(true);
und
1
boolvar:=pred(false);
beidesmal zu einem Laufzeitfehler, sofern die Laufzeitprüfung aktiviert
ist.
Yalu X. schrieb:> Der Hauptunterschied zu C liegt hier darin, dass Pascal zur Laufzeit ein> Unter- oder Überschreiten des Wertebereichs prüft.
Das muss man separat aktivieren, ist also optional. Jedoch der
wesentliche Unterschied und unschätzbare Hauptvorteil Pascal ist die
wesentlich strengere und konsequentere Typprüfung zur *Compile*zeit.
Oftmals (zumindest wesentlich öfter als bei C) kann man davon ausgehen
daß wenn es kompiliert dann wird es laufen, und zwar meistens
fehlerfrei.
Das ist auch der Grund warum Entwicklung von Software in Pascal um den
Faktor 2 schneller geht als C und dabei noch erheblich weniger Fehler
enthält.
Robert L. schrieb:> eshalb sollte es für Programmierer> die das nicht wollen, vom Compiler eine (pro Datei) einschaltbare> Warnung/Fehler geben (gibt es sowas??)
Ich glaub das gibts bei gcc, ich meine mich erinnern zu können schon
diesbezügliche Warnungen gesehen zu haben. Aber warum willst Du es nur
für einzelne Dateien haben? Eine Zuweisung in einem Ausdruck ist doch so
gut wie immer schlechter Stil. Und auch solche Sachen wie while(i--) und
ähnliches halte ich für mindestens grenzwertig.
Bernd K. schrieb:> Ich glaub das gibts bei gcc
Ja,
GCC -Wall (oder -Wparentheses)
meckert bspw. bei folgendem Code:
1
if(x=0||x>9)
2
...
1
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
2
if(x = 0 || x > 9)
3
^
Ist die Zuweisung innerhalb des booleschen Ausdruck tatsächlich
gewünscht, kann man sie klammern, und der Compiler akzeptiert sie:
1
if((x=0)||x>9)
2
...
In Leylas Übungsaufgaben sind dummer- und unnötigerweise sämtliche
Vergleiche sowieso schon geklammert, so auch die Zuweisung:
1
d) (c=1) || (b>9) || (a<-3)
Dewegen denkt hier der Compiler, die Zuweisung c=1 sei Absicht.
Um die Überprüfung durch den Compiler auf einzelne Dateien zu
beschränken, gibt es verschiedene Möglichkeiten:
- Man verwendet verschiedene Compiler-Aufrufe: für Eigencode mit und für
Fremdcode ohne die Option -Wall.
- Man schreibt in die Quelltexte, für die die Prüfung aktiviert werden
soll, die Zeile
1
#pragma GCC diagnostic warning "-Wall"
Die Option gilt dann ab der Zeile, in der das #pragma steht.
>In Leylas Übungsaufgaben sind dummer- und unnötigerweise sämtliche>Vergleiche sowieso schon geklammert, so auch die Zuweisung:>kann man sie klammern, und der Compiler akzeptiert sie:
na toll...
ich mach das immer so, weil (wie gesagt Pascal programmierer) DORT muss
man das so machen.. also nehme ich eine Variant die überall
funktioniert..
Robert L. schrieb:>>kann man sie klammern, und der Compiler akzeptiert sie:>> na toll...> ich mach das immer so, weil (wie gesagt Pascal programmierer) DORT muss> man das so machen..
Ist das tatsächlich so (habe schon lange kein Pascal mehr gemacht)?
... gerade nachgeschaut: Ja es ist so.
Gibt es irgendeinen nachvollziehbaren Grund, warum in Pascal AND und OR
stärker binden als die Vergleichsoperatoren? Das geht doch völlig an der
Realität vorbei und ist auch in keiner anderen mir bekannten Sprache so.
Wer käme denn jemals auf die Idee, diesen Ausdruck
1
a>0andb>0
als
1
(a>(0andb))>0
zu lesen?
Das genau macht aber der Pascal-Compiler – und schmeißt natürlich mit
Fehlermeldungen um sich, weil die Datentypen nirgends passen.
>Gibt es irgendeinen nachvollziehbaren Grund,
ich GLAUBE das kommt daher:
in Pascal gibt es nur "AND" das ist für Boolsche und Binäre AND das
selbe (also nicht & und &&)
AND hat also eine ähnliche "Gewichtung" wie + - * usw.
hat mal also
a, b, c: Integer;
a := 1;
b := 4;
c := 3;
man kann also
(man braucht beim if übrigens keine Klamemrn)
if a or b > c then begin
end;
und
if a + b > c then begin
end;
mit der gleichen Klammer Setzung schreiben
so gesehen (wen ich nichts übersehen habe) ist Pascal
logischer/konsequenter?
Bernd K. schrieb:> Das ist auch der Grund warum Entwicklung von Software in Pascal um den> Faktor 2 schneller geht als C
Das hätte ich vor 25 Jahren sicher auch noch so unterschrieben,
heute eher nicht mehr … viele Anfängerfehler macht man auch in C
später einfach nicht mehr.
Bernd K. schrieb:> Das ist auch der Grund warum Entwicklung von Software in Pascal um den> Faktor 2 schneller geht als C und dabei noch erheblich weniger Fehler> enthält.
Die Aussage stimmt vielleicht unter gewissen Randbedingungen, aber ganz
sicher nicht pauschal. Wer in C oder auch in C++ ernsthaft entwickeln
will, der hat auch zu befolgende Programmierrichtlinien und der nutzt
auch statische Codeanalyse (gerne eingebunden in den "nightly build").
Zudem kann man seine Build-Umgebung so einstellen, dass Warnungen als
Fehler gewertet werden und somit zwingend beseitigt werden müssen.
Zumindest bei neu geschriebenen Code-Modulen ist das sehr gut machbar.
Mark Brandis schrieb:> Bernd K. schrieb:>> Das ist auch der Grund warum Entwicklung von Software in Pascal um den>> Faktor 2 schneller geht als C und dabei noch erheblich weniger Fehler>> enthält.>> Die Aussage stimmt vielleicht unter gewissen Randbedingungen, aber ganz> sicher nicht pauschal.
Die Untersuchung würde ich allerdings auch gerne sehen.
Wenn ich so zurück denke, dann sind es in realen Entwicklungen
normalerweise nicht Syntaxprobleme, die einem das Leben schwer machen,
sondern die ganz normale algorithmische Komplexität. Das ein
industrieller Software-Entwickler seine Programmiersprache soweit
beherrscht, dass er mit Klammersetzung und/oder Strichpunkten oder was
seine Sprache sonst so an Spezialitäten aufweist keine großen
Schwierigkeiten hat, davon gehe ich mal aus. In der Vergangenheit war es
noch immer so, dass ich tagelang an Geometrie-Problemen geknobelt habe
und nicht an irgendwelchen syntaktischen Feinheiten.
Irgendwelchen kurzen Demo-Beispiele, in denen vermeintliche syntaktische
Vorteile aufgezeigt werden, würde ich ehrlich gesagt kurzerhand die
praktische Relevanz absprechen. Das sind nicht die Probleme, mit denen
man als Industrieprogrammierer zu kämpfen hat.
Ich sehe hier nicht wirklich, inwiefern mir da Pascal einen Vorteil
bieten würde. Nicht falsch verstehen: Pascal ist eine schöne Sprache und
auch gut designed. Aber von der Mächtigkeit her schenkt es sich nichts
in Relation zu C.
Robert L. schrieb:>>Gibt es irgendeinen nachvollziehbaren Grund,>> ich GLAUBE das kommt daher:>> in Pascal gibt es nur "AND" das ist für Boolsche und Binäre AND das> selbe (also nicht & und &&)> AND hat also eine ähnliche "Gewichtung" wie + - * usw.
Das scheint tatsächlich eine sehr plausible Erklärung zu sein.
Allerdings werden in einem typischen Pascal-Programm die bitweisen AND-
und OR-Verknüpfung sehr viel seltener verwendet als ihre booleschen
Pendants, so dass eigentlich die Operatorrangfolge so sein sollte, dass
sie die boolesche Variante syntaktisch besser unterstützt. Das würde
aber bedeuten, dass der Rang dieser Operatoren unterhalb der
Vergleichsoperatoren liegt, so wie das auch in praktisch allen anderen
Programmiersprachen der Fall ist.
Vielmehr noch spricht aber gegen diese Erklärung, dass die bitweisen
Operatoren offiziell gar nicht im Sprachumfang von Pascal enthalten
sind, weder im Ur-Psacal von Niklaus Wirth noch im Standard-Pascal nach
ISO 7185 noch im Extended Pascal nach ISO 102060. Sie wurde – lange,
nachdem die Operatorrangfolge festgelegt wurde – von Borland als
Spracherweiterung eingeführt.
> so gesehen (wen ich nichts übersehen habe) ist Pascal> logischer/konsequenter?
So gesehen leider doch nicht ;-)
Aber sei beruhigt: Auch in C stimmt die Operatorrangfolge (historisch
bedingt) nicht: Die booleschen Operatoren && und || sind zwar richtig
eingeordnet, nicht aber die bitweisen &, | und ^. Diese sollte
eigentlich bei den arithmetischen Operatoren liegen, also dort, wo in
Pascal die booleschen zu finden sind. Dieses Manko wurde auch in die
C-Nachfolgersprachen C++, Objective C, Java, D und C# übernommen, so
dass wir wohl noch eine ganze Weile damit leben werden müssen.
Bernd K. schrieb:> Das ist auch der Grund warum Entwicklung von Software in Pascal um den> Faktor 2 schneller geht als C und dabei noch erheblich weniger Fehler> enthält.
So viel Code ist doch in Pascal noch gar nicht geschrieben worden, als
dass man diesbezüglich eine belastbare Aussage machen könnte ;-)
Yalu X. schrieb:> Vielmehr noch spricht aber gegen diese Erklärung, dass die bitweisen> Operatoren offiziell gar nicht im Sprachumfang von Pascal enthalten> sind
Just dies wollte ich auch eben einwenden.
Zu Zeiten, als ich noch viel in Pascal geschrieben habe, war mir
jedenfalls dieses Missverhältnis der Operatorenprioritäten immer
sauer aufgestoßen. Während man in Pascal sonst „schöne Sätze“
schreiben kann (es gibt keine „Zwangsklammern“ wie nach “if”, “while”,
“for” und “case” in C), musste man bei der logischen Verknüpfung von
Bedingungen immer Klammern setzen.
Du hast natürlich bezüglich C völlig Recht mit den bitweisen Operatoren
und deren Einordnung. Gerade bei der Controllerprogrammierung wünschte
man sich schon, dass sie höher priorisiert wären als die Vergleiche.
> die das nicht wollen, vom Compiler eine (pro Datei) einschaltbare> Warnung/Fehler geben (gibt es sowas??)
Wenn man es andersrum schreibt kann das helfen:
if(105==x){bla...};
statt
if(x==105){bla...};
wenn man dann ausversehen einen Tippfehler drin hat ala:
if(105=x){bla...};
gibt es halt ne Fehlermeldung.
uwe schrieb:> Wenn man es andersrum schreibt kann das helfen:> if(105==x){bla...};
Da funktioniert halt dann, wenn einer der Operanden ein L-Value ist. Bei
1
if(a==b)...
geht das nicht.
Es gibt aber natürlich noch andere Möglichkeiten, den Ausdruck so
umzuschreiben, dass ein = statt eines == zum Fehler führt:
1
if((int)a==b)...// int ggf. durch den tatsächlichen Typ von a ersetzen
2
3
if(a-b==0)...// für arithmetische Variablen
Oder man vermeidet == komplett:
1
if(!(a-b))...// für arithmetische Variablen
2
3
if(!(a!=b))...
4
5
if(a!=b);else...
6
7
if(EQUAL(a,b))...// mit #define EQUAL(x,y) ((x) == (y))
Aber lohnt es sich wirklich, sein Programm so zu verunstalten, nur damit
einer von tausend Fehlertypen etwas leichter erkannt werden kann?
Mal ganz ehrlich: Wie oft passiert es euch, dass ihr versehentlich ein =
statt eines == schreibt? Wenn man einmal darauf hereingefallen ist, hat
man doch daraus gelernt und macht den Fehler nicht sofort wieder.
Außerdem werden solche Fehler bei Testläufen i.Allg. recht schnell
aufgedeckt, da sie einen starken Einfluss auf den Programmablauf haben.
Da gibt es in der Programmierung (nicht nur in C) oft genug ganz andere
Nüsse zu knacken.
Yalu X. schrieb:> Mal ganz ehrlich: Wie oft passiert es euch, dass ihr versehentlich ein => statt eines == schreibt? Wenn man einmal darauf hereingefallen ist, hat> man doch daraus gelernt und macht den Fehler nicht sofort wieder.>> Außerdem werden solche Fehler bei Testläufen i.Allg. recht schnell> aufgedeckt, da sie einen starken Einfluss auf den Programmablauf haben.> Da gibt es in der Programmierung (nicht nur in C) oft genug ganz andere> Nüsse zu knacken.
Vollkommen richtig.
Falls nichts dagegen spricht, sollte eigentlich immer -Wall -Werror o.ä.
eingestellt sein. Und nur wenn es nicht anders geht, dann per Pragma
etc. das Verhalten des Compilers gezielt geändert werden.
Thread beobachten
Seitenaufteilung abschalten