Berichtigungen im Code

[Marcw13]

Ich dachte mir mal, da ich gerade versuche mit C zu programmieren (ich kann auch noch keine andere Sprache), dass das hier ein ganz nützliches Thema sein könnte, in dem Anfänger so wie mir geholfen wird, wenn mal ein Problem entsteht.

Dann will ich auch gleich mal anfangen:
Ich lese im Moment das Buch "C Programmieren von Anfang an" und habe nun ein kleines Problem in einem Programm.
Die letzte Zeile lautet:

printf("\n\tDie größere Zahl lautet %i"), (x<y) ? x : y);

Ich bekomme aber dem Error: syntax error befone ')' token. habe aber keine Ahnung was ich falsch mache oder auch nicht was das heißen soll.

Ich hoffe, das ich nicht der einzige bleibe, der dieses Thema benutzt und bedanke mich bei allen, die anderen helfen wollen.

 

[TDH]

Du hast eine Klammer zu viel oder dich vertippt hier.

 

[macaneon]

Es fehlt auf den ersten Blick betrachtet eine schließende Klammer.

Edit:
Nein, ich glaube, vor der Formel fehlt eine öffnende.

 

[Nighthawk]

Du hast da eine Klammer zuviel (nach dem %i").

 

[Marcw13]

Wow gleich so viele danke.

Das war der erste Feher aber jetzt bekomme ich stattdessen den error: syntax error at end of input

 

[Skeeve]

Den neuen Syntax (T)Error kann ich nicht erklären, Dein Programm hat aber noch einen logischen Fehler, da es nicht die größere, sondern die kleinere Zahl anzeigt.

 

[below]

Wie einige schon sagten, richtig ist:

printf("\n\tDie größere Zahl lautet %i", (x<y) ? x : y);

Um den zweiten Fehler zu finden müsste man mal Dein ganzes Programm sehen

Alex

 

[below]

Dein Programm hat aber noch einen logischen Fehler, da es nicht die größere, sondern die kleinere Zahl anzeigt.

Das zeigt, warum man Anfänger erstmal mit diesem C Konstrukt verschonen sollte.
Ein

int i;
if (x>y)
i = x;
else
i = y;

wäre sicher klarer.

Alex

 

[Marcw13]

Danke an alle ich hab ihn jetzt ich vergesse immer kleine Zeichen, die aber trotzdem von großer Bedeutung sind wie diesmal }

 

[Skeeve]

Das zeigt, warum man Anfänger erstmal mit diesem C Konstrukt verschonen sollte.
Ein

int i;
if (x>y)
i = x;
else
i = y;

wäre sicher klarer.

Das hängt vom Standpunkt ab. Es gibt Leute die würden sagen, daß auch das nicht klar genug ist und man doch bitte schreiben möge:

int maximum;
if (x>y) {
    maximum= x;
}
else {
    maximum= y;
}

Fortgeschritten Perl Programmierer finden dieses Konstrukt sehr hübsch:

my $maximum= [ $x => $y ] -> [ $x <= $y ]

Letzteres nur um Perls Nimbus als unverständliche Sprache zu untermauern.

 

[Amin Negm-Awad]

Das hängt vom Standpunkt ab. Es gibt Leute die würden sagen, daß auch das nicht klar genug ist und man doch bitte schreiben möge:

int maximum;
if (x>y) {
    maximum= x;
}
else {
    maximum= y;
}

Count me in! Es dürfte jedem klar sein, was der Code bedeutet.

Fortgeschritten Perl Programmierer finden dieses Konstrukt sehr hübsch:

my $maximum= [ $x => $y ] -> [ $x <= $y ]

Letzteres nur um Perls Nimbus als unverständliche Sprache zu untermauern.

Manche Leute verstehen möglichst unklare Sourcen als Pimmelverlängerung. Eigentlich sollte man denen einen Porsche schenken.

 

[Skeeve]

Okay… laßt uns abschweifen…

Manche Leute verstehen möglichst unklare Sourcen als Pimmelverlängerung. Eigentlich sollte man denen einen Porsche schenken.

Das ist nur so lange unklar, wie man nicht zu 133t gehört

Nein! Dummfug. Ich empfinde den dargestelltn Code als hübsch und kann mich daran erfreuen ihn zu verstehen zu versuchen. Das mag geekig sein, ist mir aber auch egal.

In produktivem Code würde ich das natürlich nicht einsetzen. Allerdings dieses hier schon:

1<<a>>1

Es sei denn, Du kannst mir treffenderen Code geben und mich davon überzeugen, daß "meiner" wirklich nur der Verwirrung dient.

Ach! Was den Porsche angeht: Ich verzichte aus folgenden Gründen:

• Ist mir zu schnell
• Schluckt zuviel Treibstoff
• Meine Familie paßt nicht rein
• geschweige denn das Gepäck für uns
• Ich hätte schwierigkeiten mich da rein zu quälen

 

[below]

Ach! Was den Porsche angeht: Ich verzichte aus folgenden Gründen:

• Ist mir zu schnell
• Schluckt zuviel Treibstoff
• Meine Familie paßt nicht rein
• geschweige denn das Gepäck für uns
• Ich hätte schwierigkeiten mich da rein zu quälen

Sehr gut, ich nehm ihn!

Alex

 

[Skeeve]

Sehr gut, ich nehm ihn!

Wende Dich vertrauensvoll an Amin.

 

[Amin Negm-Awad]

Okay… laßt uns abschweifen…


Das ist nur so lange unklar, wie man nicht zu 133t gehört

Nein! Dummfug. Ich empfinde den dargestelltn Code als hübsch und kann mich daran erfreuen ihn zu verstehen zu versuchen. Das mag geekig sein, ist mir aber auch egal.

Wenn du Geek als Fachmann meinst, so ist es nicht geekig. Der Code ist unklar. Ein Fachmann würde auf klaren Code bestehen.

In produktivem Code würde ich das natürlich nicht einsetzen.

Wozu dann überhaupt? Um sich als geekig zu bezeichnen?

Allerdings dieses hier schon:

1<<a>>1

Es sei denn, Du kannst mir treffenderen Code geben

Kommt darauf an, was der Wertebereich von a ist,was wiederum vom Problemabhängt, welches du nicht beschreibst. In jedem Falle ist bereits

(1<<a)>>1

treffender, weil es die Operatorprioritäten expliziert. Aber es zeigt dann auch gleich, dass es viel klarer geht, als etwas erst nach links zu schieben, um es dann nach rechts zu schieben:

1<<(a-1)

Das stimmt freilich nur dann, wenn das höchste Bit nie gesetzt ist,was ich mangels Problembeschreibung nicht beurteilen kann. Aber auch dann würde ich ein & bevorzugen, um dieses Ziel zu explizieren. So ist das nämlich ein "Seiteneffekt", der sicher gerne übersehen wird. Wetten wir, dass bestimmt 30 % den Unterschied nicht bemerken?

und mich davon überzeugen, daß "meiner" wirklich nur der Verwirrung dient.

Siehe oben. Man kann das allerdings nicht verallgemeinern. Wenn es dir inhaltlich wirklich um einWobbel-Dobbel-Hin-Her-Jojo-Code geht, mag sogar deine Formulierung klarer sein. (man hat so etwas etwa, wenn man Register von Controllern lädt.)

Wenn es dir darumgeht, um a-1 zu schieben und das höchste Bit zu löschen, ist er völlig unklar.

Ach! Was den Porsche angeht: Ich verzichte aus folgenden Gründen:
[*]Ist mir zu schnell

Du bist kein echter Mann

[*]Schluckt zuviel Treibstoff

Du bist kein echter Mann.

[*]Meine Familie

Du bist kein echter Mann.

[*]geschweige denn das Gepäck

Du bist kein echter Mann.

[*]Ich hätte schwierigkeiten mich da rein zu quälen

Du bist kein echter Mann.

 

[Amin Negm-Awad]

Wende Dich vertrauensvoll an Amin.

Alex bekommt den nicht. Der hat viel zu viel Stil als das er "geekigen" Code schreiben würde.

 

[Skeeve]

Wenn du Geek als Fachmann meinst, so ist es nicht geekig. Der Code ist unklar. Ein Fachmann würde auf klaren Code bestehen.

Was ist da unklar?

Wozu dann überhaupt? Um sich als geekig zu bezeichnen?

Weil es hübsch aussieht.

Kommt darauf an, was der Wertebereich von a ist,was wiederum vom Problemabhängt, welches du nicht beschreibst.

a ist ein Integer im Bereich 0-9. Es soll dasjenige Bit gesetzt werden, das a angibt, wobei wir aber bei 1 zu zählen beginnen (also 1= Bit 0 wird gesetzt) und 0 bedeutet, daß kein Bit gesetzt ist.

In jedem Falle ist bereits

(1<<a)>>1

treffender, weil es die Operatorprioritäten expliziert.

Mit anderen Worten: Du schreibbst statt a+b-c auch (a+b)-c. Und wenn nicht, warum nicht?

Aber es zeigt dann auch gleich, dass es viel klarer geht, als etwas erst nach links zu schieben, um es dann nach rechts zu schieben:

1<<(a-1)

Was aber bedeutet, daß man wissen muß, daß ein , Verschieben um -1 nach links einem Verschieben um 1 nach rechts entspricht. Ganz ehrlich: Ich war mir da nicht so sicher.

Das stimmt freilich nur dann, wenn das höchste Bit nie gesetzt ist,was ich mangels Problembeschreibung nicht beurteilen kann.

Okay. Die Problembeschreibung habe ich Dir geschuldet und mit den Seiteneffekten (die hier zu vernachlässigen sind) hast Du recht.

Wenn es dir darumgeht, um a-1 zu schieben

Ja. Ging es. Wobei ich meines immer noch klarer finde, wegen der angesprochenen -1-Problematik.

Du bist kein echter Mann
Du bist kein echter Mann.
Du bist kein echter Mann.
Du bist kein echter Mann.
Du bist kein echter Mann.

Ich werde das nicht abstreiten.

 

[Amin Negm-Awad]

Was ist da unklar?

Hatte ich doch geschrieben:
a) Die Operatorenbindung
b) Ob der Seiteneffekt des gelöschten obersten Bits gewollt ist.

Weil es hübsch aussieht.

Schönheit steht im Auge des Betrachters. Ich finde eher, dass das wie eine Teddybär-SMS aussieht.

a ist ein Integer im Bereich 0-9. Es soll dasjenige Bit gesetzt werden, das a angibt, wobei wir aber bei 1 zu zählen beginnen (also 1= Bit 0 wird gesetzt) und 0 bedeutet, daß kein Bit gesetzt ist.

Dann kannst du dich glücklich schätzen, dass der von dir übersehende Seiteneffekt keine Rolle spielt.

Mit anderen Worten: Du schreibbst statt a+b-c auch (a+b)-c. Und wenn nicht, warum nicht?

Weil das Menschen seit der Grundschule wissen. Wenn es um Lesbarkeit geht, geht es um Lesbarkeit für den Menschen

Übrigens, wenn etwa zu einer Variablen eine Differenz addiert werden soll, so formuliere ich das durchaus so:

a+(b-c)

Das hat mathematisch oder programmiertechnisch keinen Vorteil oder Nachteil. Es zeigt aber die Semantiker Jung will zu a die Differenz von b zu c addieren. Mit klareren Variablennamen (gerne: Position und Weite) ist das dann häufig sofort einsichtig und selbsterklärend.

Was aber bedeutet, daß man wissen muß, daß ein , Verschieben um -1 nach links einem Verschieben um 1 nach rechts entspricht. Ganz ehrlich: Ich war mir da nicht so sicher.

Nein, das muss man nicht wissen. Man muss wissen, dass wenn man eine Stelle weniger nach links verschiebt,dies einem Verschieben nach links entspricht. Da steht nicht:

(1<<a)<<-1

sondern

1<<(a-1)

Das hat wenig mit C oder Mathematik zu tun. Wenn du drei Waggons weiter den Speisewagen besuchst,wirst du auch nicht vier Waggons ablaufen, um dann wieder einen zurück zu gehen.

Okay. Die Problembeschreibung habe ich Dir geschuldet und mit den Seiteneffekten (die hier zu vernachlässigen sind) hast Du recht.

Die du offenbar auch jetzt noch nicht übersehen hast. Die beiden letzten Codezeilen erzeugen völlig unterschiedliche Ergebnisse, ganz unabhängig von negativen Verschiebungen.

Ja. Ging es. Wobei ich meines immer noch klarer finde, wegen der angesprochenen -1-Problematik.

Das macht der Code jedoch nicht! Er verschiebt ein Bit weniger – was du wolltest – und löscht das oberste Bit. Das mag in deinem Anwendungsfall gleichgültig sein. Alleine der Umstand, dass du das nicht sahst, zeigt, dass der Code unklar ist. Wieso in Gottes Namen formulierst du nicht genau das, was du willst? Was willst du damit beweisen?

Ich werde das nicht abstreiten.

Ich dachte,dies sei dieselbe Kategorie wie "Geek".

 

[Skeeve]

Dann kannst du dich glücklich schätzen, dass der von dir übersehende Seiteneffekt keine Rolle spielt.

Ich behaupte einfach frech: Wäre der Wertebereich von a größer (also ab 15) hätte ich mir mehr gedanken darum gemacht!

Weil das Menschen seit der Grundschule wissen. Wenn es um Lesbarkeit geht, geht es um Lesbarkeit für den Menschen

D.h. also wenn Menschen ähnlich lange mit Bitschiebereien zu tun hätten, wie mit Grundrechenarten, könnte man sich die von Dir gewünschten Klammern sparen. Okay.

Nein, das muss man nicht wissen. Man muss wissen, dass wenn man eine Stelle weniger nach links verschiebt,dies einem Verschieben nach links entspricht.

Ich wage zu widersprechen. Denn durch Dein Konstrukt tritt ein anderer grenzwertiger Seiteneffekt auf. Eben der, was passiert, wenn a den Wert 0 hat. Das ist einer der zulässigen Werte für a. Wenn man jemand ist, dem man für das Verständnis von Bitschiebereien Klammern geben sollte, dann ist man sicherlich auch jemand, der nicht weiß, daß 1<<-1 (bei a==0) dasselbe ergibt wie 1>>1.

Das hat wenig mit C oder Mathematik zu tun. Wenn du drei Waggons weiter den Speisewagen besuchst,wirst du auch nicht vier Waggons ablaufen, um dann wieder einen zurück zu gehen.

Das zeigt mir, daß Du keine Freundin/Frau hast oder, wenn doch, eine, die keine richtige Frau ist. Weißt Du, wie eine Frau einen Weg beschreibt? Um das mal beim Speisewagenbeispiel zu bleiben: "Ute, Du weißt doch, wo die Schlafwagen sind, nä? In die Richtung (deutet nach hinten). Wenn Du bei denen angekommen bist, dann bist Du schon einen Wagen zu weit"

Die du offenbar auch jetzt noch nicht übersehen hast. Die beiden letzten Codezeilen erzeugen völlig unterschiedliche Ergebnisse, ganz unabhängig von negativen Verschiebungen.

Nicht im angegebenen Grenzbereich, ansonsten: Ja.

Wieso in Gottes Namen formulierst du nicht genau das, was du willst? Was willst du damit beweisen?

Weil es sich beim Programmieren so ergeben hat. Als ich vor dem Problem stand, das angegebene Bit zu setzen, bin ich zunächst auf dieses Konstrukt gekommen: 2**a/2. Da hätte ich aber noch die Nachkommastellen abschneiden müssen. Dann fiel mire ein, daß ich /2 ja auch mit >>1 erreiche, also: 2**a>>1 uhd dann erst ging mir auf, daß 2** auch 1<< sein kann und ich schrieb 1<<a>>1. Das hat mir gefallen und so blieb es stehen.

 

[Amin Negm-Awad]

Ich behaupte einfach frech: Wäre der Wertebereich von a größer (also ab 15) hätte ich mir mehr gedanken darum gemacht!

Das mag ja stimmen. Aber jemand der das liest muss sich diese Gedanken machen. Und der sieht dann, wenn er Ahnung hat: Wird um a-1 verschoben und das oberste Bit gelöscht.

D.h. also wenn Menschen ähnlich lange mit Bitschiebereien zu tun hätten, wie mit Grundrechenarten, könnte man sich die von Dir gewünschten Klammern sparen. Okay.

Selbstverständlich. Und wenn englische Wörter anders geschrieben würden, dann wären anders geschriebene Variablennamen lesbarer.

Es kommt ganz und gar auf das menschliche Verständnis an. Und das hängt natürlich davon ab, was Menschen lernen.

Ich wage zu widersprechen. Denn durch Dein Konstrukt tritt ein anderer grenzwertiger Seiteneffekt auf. Eben der, was passiert, wenn a den Wert 0 hat. Das ist einer der zulässigen Werte für a. Wenn man jemand ist, dem man für das Verständnis von Bitschiebereien Klammern geben sollte, dann ist man sicherlich auch jemand, der nicht weiß, daß 1<<-1 (bei a==0) dasselbe ergibt wie 1>>1.

Jede Operation hat Bereichsprobleme. Es geht darum, dass dein Ausdruck etwas ganz anderes macht, nämlich das oberste Bit maskieren. In meinem Code steht eine Verschiebung uns es wird eine verschiebung vorgenommen. Dies hat das Problem der Bereichsprüfung bei Verschiebungen.

In deinem Code steht eine Verschiebung und es wird eine Verschiebung vorgenommen und eine Bitmaskierung. Dies hat das Problem der Bereichsprüfung bei Verschiebungen. Und es hat das Problem der Bitmaskierung. Dies ist ein Effekt, der dort semantisch nicht explizit steht. Da fragt sich der geneigte Leser: "Will der dat wirklich?" Und in diesem Falle war es sogar so, dass du das gar nicht wolltest! Klarer kann man das Problem doch kaum machen!

Das zeigt mir, daß Du keine Freundin/Frau hast oder, wenn doch, eine, die keine richtige Frau ist.

Das würde sie in Abrede stellen wollen.

Weißt Du, wie eine Frau einen Weg beschreibt? Um das mal beim Speisewagenbeispiel zu bleiben: "Ute, Du weißt doch, wo die Schlafwagen sind, nä? In die Richtung (deutet nach hinten). Wenn Du bei denen angekommen bist, dann bist Du schon einen Wagen zu weit"

Ich würde das zwar nicht als typisch weiblich bezeichnen. Aber unabhängig von der Geschlechtsspezifizität dieser Beschreibung, würde ich eine solche im Sourcecode eben nicht als klar bezeichnen, sondern als ganz und gar hinrissig.

(In Wahrheit taucht übrigens bei jeder Wegbeschreibung einer Frau ein Schuhgeschäft auf. Aber das nur am Rande.)

Nicht im angegebenen Grenzbereich, ansonsten: Ja.

Der Leser deiner Source weiß erst einmal nicht von deinem Grenzbereich.

Weil es sich beim Programmieren so ergeben hat. Als ich vor dem Problem stand, das angegebene Bit zu setzen, bin ich zunächst auf dieses Konstrukt gekommen: 2**a/2. Da hätte ich aber noch die Nachkommastellen abschneiden müssen. Dann fiel mire ein, daß ich /2 ja auch mit >>1 erreiche, also: 2**a>>1 uhd dann erst ging mir auf, daß 2** auch 1<< sein kann und ich schrieb 1<<a>>1. Das hat mir gefallen und so blieb es stehen.

Man merkt sofort, dass die sein deutlich klarerer Gedankengang ist als: "Ich will um a-1 verschieben, also schreibe ich 1<<(a-1)"

Abwegig, dies als klar zu bezeichnen. Toital kompliziert von mir gedacht. Einfach das machen, was man machen will. WO KOMMEN WIR DENN DAHIN!!!!!!!