(Wert & 1) zu komplex oder Grundlagenwissen?

[Panke]

Ich will mir beim lesen von Code nicht ständig die Frage stellen müssen, was mir der Autor damit wohl sagen will.
Natürlich weiß ich, dass bei (x & 1) für alle ungeraden x gilt. Aber wenn ich (x & 1) irgendwo im Code sehe und es soll
tatsächlich auf ungerade geprüft werden, brauche ich einen Schritt mehr.

(odd(x)) ==> Prüfung auf ungerade (steht ja da)
(x % 2 != 0) ==> Prüfung auf ungerade, hab ich in der Grundschule schon so gelernt
(x & 1) ==> Ist das letzte bit gesetzt? ==> Wie, flags? ==> Ach ne, ob die Zahl ungerade ist.

Imo, gibt es für die dritte Möglichkeit daher keinen objektiven Grund, denn schneller ist es nur
auf exotischen Systemen. Und bei der Optimierung halte ich es mit Djikstra.

Ich weiß nicht, warum du bei diesem Thema ständig so weit abschweifst. Jedenfalls kommen
wir hier auch nicht zu einem Konsens. Deswegen belasse ich es dabei.

[Xin]

Ich weiß nicht, warum du bei diesem Thema ständig so weit abschweifst.

Ich finde es etwas ärgerlich, wenn man Dinge in einem großen Kontext anordnet, dass man das als Abschweifen beschreibt. Ich programmiere inzwischen seit über 25 Jahren und entdecke dabei auch Probleme, wie auch Lösungen, für Probleme, die sich Dir vielleicht erst Jahre später auftun. Und in den letzten 10 Jahren lag ich mit meinen Prognosen eigentlich ziemlich gut.

Eine offensichtliche Problemlösung kann auch Auslöser eines viel größeren Problems sein. Die richtige Lösung ist dann ein kleines Problem nicht zu lösen. (x & 1) ist kein großes Problem. Also unterrichte ich das Problem und weshalb wir das Problem nicht über die Programmiersprache anders lösen werden.

99% der Vorschläge, die man mir macht, wie ich Dinge besser machen sollte, habe ich schon ausprobiert. Und dass wir keinen Konsens finden, liegt zum Beispiel daran, dass ich bei (x&1) bisher nicht im Entferntesten an Flags gedacht habe, denn das ist überhaupt keine sinnvolle Schreibweise um Flags abzufragen. Magic Numbers halte ich für schlechten Programmierstil, deswegen kann (x&1) kein Flag sein, denn sonst würde da bei mir ( x & FlagType.Flag ) stehen oder x.IsFlagged().

Ich habe inzwischen Wege, die verhältnismäßig gerade von a nach b führen und auch noch aktive Codes aus dem letzten Jahrtausend laufen. Irgendwas muss ich also richtig gemacht haben. Die Erfahrungen daraus kann man mitteilen, falls es wen interessiert.

Ich könnte jetzt zum Beispiel erklären, wie ich Flags verwende.
Ich schweife ab? dr;tl?
Okay, lassen wir das.

[oenone]

Ich will mir beim lesen von Code nicht ständig die Frage stellen müssen, was mir der Autor damit wohl sagen will.
Natürlich weiß ich, dass bei (x & 1) für alle ungeraden x gilt. Aber wenn ich (x & 1) irgendwo im Code sehe und es soll
tatsächlich auf ungerade geprüft werden, brauche ich einen Schritt mehr.

(odd(x)) ==> Prüfung auf ungerade (steht ja da)
(x % 2 != 0) ==> Prüfung auf ungerade, hab ich in der Grundschule schon so gelernt
(x & 1) ==> Ist das letzte bit gesetzt? ==> Wie, flags? ==> Ach ne, ob die Zahl ungerade ist.

Imo, gibt es für die dritte Möglichkeit daher keinen objektiven Grund, denn schneller ist es nur
auf exotischen Systemen. Und bei der Optimierung halte ich es mit Djikstra.

Ich stimme dir hier zu, möchte aber ergänzen, dass bei sowas auch Kommentare hilfreich sind. Also immer brav kommentieren!

Code: Alles auswählen

//do something with odd numbers
if (x & 1) {

Hier ist jedem klar, was abgefragt wird.

[beginner123]

Hallo,

jetzt melde ich mich auch mal noch kurz zu Wort .

Also ich empfand die Sache mit dem if( wert & 1 ) ehrlich gesagt, jetzt eher als Bereicherung. Und ich sehe es auch so, dass zum Lernen eben auch eine gewisse Bereitschaft dazugehört, sich auch einmal mit Dingen auseinander zu setzen, die man eben nicht auf den 1. Blick versteht. Somit fragt man nach - und das tolle ist ja - man bekommt hier wirklich schnell eine Antwort bzw. Hilfe. Und zwar Hilfe in der Art, dass es einerseits erklärt wird, aber man auch zum "Selberdenken" aufgefordert wird. Das finde ich eigentlich am besten. Und so lernt man eben. Ich glaube, das wird mir in der Programmierung - zumindest am Anfang - wahrscheinlich noch öfters so gehen, dass ich Ausdrücke sehe, mit denen ich erstmal nichts anfangen kann. Aber ich bin halt auch neugierig. Ich will ja wissen, was sich hinter xxx verbirgt, bzw. wie was funktioniert.

Klar, wenn zuviele neue Dinge auf einmal auftauchen, dann verwirrt das natürlich. Ist mit Sicherheit immer ein Gradwanderung, wieviel "Neues" man je nach "Ausbildungsstand" in so einen Kurs reinbringt. Aber in dem Beispiel passte es - fand ich zumindest - gut. Natürlich - es wäre jetzt auch nicht nachteilig gewesen, wenn die Aufgabe nun von vornherein mit modulo beschrieben worden wäre. Aber es war zumindest ein Vorteil für mich, dass es statt dessen mit dem Binäroperator gelöst wurde, denn das kann ich jetzt einfach. Und der Vorteil überwiegt meiner Ansicht nach .

Grüße
beginner

[beginner123]

oh mann, grad gesehen..., also meine Rechtschreibfehler häufen sich auch ganz schön mittlerweile...
Es heißt natürlich "Gratwanderung" und "Literatur"... na ja manchmal schreibt man eben schneller als man denkt *kopfschüttel*

[Panke]

Mein Punkt war, dass Prüfung ob eine Zahl x ungerade ist mittels (x & 1) schlechter Stil ist und daher Anfängern nicht vorgelebt werden sollte. Dass die Bitoperation an sich ziemlich simpel ist, und dass Bitoperationen einem C-Neuling zugemutet werden dürfen, ist davon ja völlig unberührt.

Wie man sieht, gibt es zu diesem Punkt aber deutlich unterschiedliche Meinungen. Zugegeben zähle ich bei (x&1) Erbsen, aber gerade wenn man Anfängern etwas beibringt, sollte man gute Angewohnheiten gleich verankern.

[fat-lobyte]

Wie man sieht, gibt es zu diesem Punkt aber deutlich unterschiedliche Meinungen. Zugegeben zähle ich bei (x&1) Erbsen, aber gerade wenn man Anfängern etwas beibringt, sollte man gute Angewohnheiten gleich verankern.

Seh ich auch so! beginner123, freut mich dass du was dabei gelernt hast. Und ein guter Programmierer sollte auch *verstehen* können was das bedeutet.
Aber solche Späße in eine if-Bedingung zu schreiben, vor allem dann wenn es einfache alternativen gibt, sollte man sich nicht angewöhnen.

Mein Hauptpunkt war: Können: ja, auf jeden fall! ABER nachdem man weiß wies geht, sollte man es gleich wieder vergessen, denn es gibt meist bessere Möglichkeiten - das gilt für Bitspielereien wie auch Listen, Vektoren und vor allem Strings.

[Xin]

Mein Hauptpunkt war: Können: ja, auf jeden fall! ABER nachdem man weiß wies geht, sollte man es gleich wieder vergessen, denn es gibt meist bessere Möglichkeiten - das gilt für Bitspielereien wie auch Listen, Vektoren und vor allem Strings.

Genau! Können ja, aber nicht anwenden.
Das macht man erst wieder, wenn man sich auf Optimierung spezialisiert und die besseren Möglichkeiten einen ausbremsen. :->

[fat-lobyte]

Genau! Können ja, aber nicht anwenden.
Das macht man erst wieder, wenn man sich auf Optimierung spezialisiert und die besseren Möglichkeiten einen ausbremsen. :->

Tja, was soll man dazu Antworten... Auch durch deinen sarkastischen Kommentar wird meine Aussage nicht falscher.

Außerdem hast du recht! Erst schreiben, dann messen, dann Profiling und DANN erst überlegen wie mans anders schreiben könnte. Abstraktion ist der ganze Zweck einer hochsprache.