Ich bezweifle nicht, dass dieser Code das genialste Stückchen Software
auf Erden ist, den schnellsten und kürzesten Code, um das gegebene
Problem zu lösen, erzeugt, und auch sonst das Leben ein Stück
lebenswerter macht.
Der gezeigte Code macht auch deutlich, dass die bei manchen
Programmierern teilweise vorherrschende Meinung, Kommentare
erleichterten das Verständnis oder auch nur die Verwendung in eigenen
Programmen, hoffnungslos überbewertet ist.
Ich nehme mal an, dass dieser Code eine 32bit-Zahl in Binärschreibweise
darstellt. Und ich nehme mal an, dass der Parameter d die Position des
LSBit (entweder links oder rechts) angibt. Und ich nehme mal an, dass es
sonst keinerlei Nebenwirkungen gibt.
Und natürlich hagelt es jetzt schnippische Antworten wie etwa "steht
doch da: "//d: 0/1 forward/backward". Das ist für mich aber kein
verwertbarer Kommentar, das könnte genausogut eine dieser kryptischen
Codierungen für irgendwelche Linux-Tools zur automatischen
Kommentargenerierung sein, aber kein wirklich menschenverständlicher
Hilfetext. Und wenn ich den Code erst durcharbeiten muss, um die
Kommentare zu verstehen, dann, ja dann haben die Kommentare wirklich
ihren Zweck vollumfänglich erfüllt.
Arduino ist doch C++. Da geht es wirklich Typ-Unabhängig. Ständig "d"
abzufragen ist ziemlich ineffizient, besser ist es zwei Schleifen mit
äußerer Unterscheidung zu verwenden:
Worüber der eine oder andere Compiler stolpern dürfte, ist das hier
verwendete typeof, das ist bislang kein Bestandteil des
C-Sprachstandards, sondern nur eine nichtportable Erweiterung mancher
Compiler.
Niklas G. schrieb:> Arduino ist doch C++. Da geht es wirklich Typ-Unabhängig. Ständig "d"> abzufragen ist ziemlich ineffizient, besser ist es zwei Schleifen mit> äußerer Unterscheidung zu verwenden:
Das sind Kommentare wie ich sie mag ... zum nachdenken/lernen.
Thilo L. schrieb:> Ich bezweifle nicht, dass dieser Code das genialste Stückchen Software> auf Erden ist,
... das Gegenteil - rumgesülze!
Apollo M. schrieb:> ... aus meiner (arduino, uC) Giftküche,
"Giftküche", offensichtlich gut gewählt, da einige Hirne gleich unter
Drogen zu stehen scheinen.
Coding ist Art und darüber lässt sich bekanntlich lange diskutieren ...
Es wäre auch interessant, wenn regelmäßig Code Snippets zur Diskursion
gestellt werden. Dann gibt es vielleicht hier mal zur Abwechselung
wieder mehr Inhalt!!!
Klaus W. schrieb:> Wenn man gcc hat, kann man auch gleich eine Formatierung für Binärzahlen> in printf einbauen und z.B. mit %b ausgeben.
printf scheidete vom memory footprint aus.
Niklas G. schrieb:> Arduino ist doch C++.
Von C++ habe ich zu wenig Ahnung ..., aber vielleicht wird das mal
irgendwann besser.
Niklas G. schrieb:> Ständig "d"> abzufragen ist ziemlich ineffizient,
Inefficient? bzgl. memory size oder run time oder beides?
Wie immer kommt drauf an ...
DerEinzigeBernd schrieb:> Worüber der eine oder andere Compiler stolpern dürfte, ist das hier> verwendete typeof, das ist bislang kein Bestandteil des> C-Sprachstandards,
Stimmt leider, ausprobiert mit xc8 ...
Apollo M. schrieb:> Inefficient? bzgl. memory size oder run time oder beides?> Wie immer kommt drauf an ...
Runtime. In jedem Schleifendurchlauf sind gleich 2 Fallunterscheidungen,
die dann z.B. 32x gemacht werden müssen. Hat man wie bei mir nur eine
Abfrage, kommt die Unterscheidung nur 1x. Fallunterscheidungen sind
allgemein langsam, insbesondere Prozessoren mit (längerer) Pipeline
(z.B. ARM, gibts ja auch bei Arduino), daher sollte man davon möglichst
wenige in inneren Schleifen haben.
Bei Prozessoren mit Branch-Prediction ist es nicht so schlimm weil sich
d nicht ändert, aber das haben nicht viele Mikrocontroller (Cortex-M7
z.B. hat es).
Apollo M. (Firma: @home) (majortom)
17.06.2022 08:36
>... aus meiner (arduino, uC) Giftküche, type val independent
Einerseits finde ich es gut, wenn jemand Code posted, damit die anderen
etwas lernen können.
Andererseits würde ich dir dringend empfehlen, anderseits würde ich dir
dringend das Buch "weniger schlecht programmieren"
https://oreilly.de/produkt/weniger-schlecht-programmieren/
oder "Clean Code" ans Herz legen falls du mal vor hast, leserlichen Code
zu schreiben.
Niklas G. schrieb:> Fallunterscheidungen sind> allgemein langsam
Das könnte man auf die Spitze treiben und gleich ganz drauf verzichten
(erstmal). Nur wenn man es wirklich braucht, lässt sich der String im
Nachhinein drehen.
Dann kommt das Konvertieren bis dahin komplett ohne Fallunterscheidung
aus.
Da es ja auch nur 16 Möglichkeiten für die Teilstrings zwischen den
Punkten gibt, könnte eine Tabelle dafür effizienter sein, mit jeweils
einem Nibble als Index.
Zumindest würde ich das mal auf dem jeweiligen System als eine
Möglichkeit testen.
Das würde dann etwa so aussehen:
So habe ich acht Schleifendurchläufe mit je:
- Berechnung Tabellenzugriff mit einem &
- memcpy für je 5 Byte
- Zeigerkorrektur mit -=
- 32 Bit um 4 nach rechts schieben
Danach noch den String terminieren, und evtl. den String drehen
(Schleife mit halber Stringlänge)
(Die abschließende 0 überschreibt einen vorher versehentlich
geschriebenen Punkt. Das nehme ich in Kauf, weil es umständliche
Fallunterscheidungen eliminiert.)
Wen man sehr mit Speicher geizt, tut vielleicht die Tabelle weh. Aber
umständlicher Code kostet ja auch...
Gerhard schrieb:> leserlichen Code> zu schreiben.
Für wenn? - Analphabeten, sind nicht meine Zielgruppe!
Ich mag den Code kompakt, das sinnlose Klammern von einzeiligen if/else
.. Anweisungen kann ich nicht ausstehen, genauso wenig die oft nur
sinnleeren Komentare.
Gerhard schrieb:> oder "Clean Code" ans Herz
Kenn ich und überzeugt mich nicht, genau so wenig wie MiSRA ...
und Empfehlungen von selbsternannten Experten sind mir besondern
unerwünscht!
Apollo M. schrieb:> char rxBuf[42];
Wieso eigentlich 42?
Wenn ich mich nicht verzähle reichen 40.
32 mal '0' oder '1', 7 mal '.' zum Trennen und eine abschließende \0.
Schönes Beispiel dafür, wie man C als "Klartextverschlüsselung"
missbrauchen kann. Völlig kontraproduktiv. Wenn ich eine "Hochsprache"
einsetze, ist das Ziel, die Sache leichter les- und wartbar zu machen.
Mein Gott, selbst die Asm-Umsetzung dieses Bullshits ist zwar nicht
nennenswert schneller, aber sehr viel besser lesbar...
c-hater schrieb:> Mein Gott, selbst die Asm-Umsetzung dieses Bullshits ist zwar nicht> nennenswert schneller, aber sehr viel besser lesbar...
Ich muss mich hier nochmal korrigieren. Die wirklich durchdachte
Asm-Umsetzung ist deutlich schneller, deutlich kleiner und immer noch
deutlich besser lesbar...
c-hater schrieb:> Mein Gott, selbst die Asm-Umsetzung dieses Bullshits ist zwar nicht> nennenswert schneller, aber sehr viel besser lesbar...
Was geht mich fremdes Elend an, ich kann es sehr gut lesen und mehr
interessiert nicht!
Asm-Affe, nimm besser zwei Bananen und entspann in deiner
closed-asm-box!
Apollo M. schrieb:> c-hater schrieb:>> Mein Gott, selbst die Asm-Umsetzung dieses Bullshits ist zwar nicht>> nennenswert schneller, aber sehr viel besser lesbar...>> Was geht mich fremdes Elend an, ich kann es sehr gut lesen und mehr> interessiert nicht!> Asm-Affe, nimm besser zwei Bananen und entspann in deiner> closed-asm-box!Walter T. schrieb:> Was willst Du erreichen - mit dem Thread und mit der Funktion?
Einfach mal provozieren und anschließend rumpöbeln. Etwas anderes ist
offenbar nicht der Sinn - denn darum, jemandem zu helfen, der das
gleiche Problem haben könnte, geht's ganz offensichtlich nicht.
>c-hater schrieb:>> Mein Gott, selbst die Asm-Umsetzung dieses Bullshits ist zwar nicht>> nennenswert schneller, aber sehr viel besser lesbar...
Die Formulierung "Bullshit" mag ich nicht, aber in einem Punkt muss ich
dir Recht geben: Dieser Banalalgortihmus formuliert jemand der mit C
umgehen kann deutlich besser. Es gibt keinerlei Grund, diesen
Algorithmus nicht klar und deutlich hinzuschreiben außer vielleicht die
Begründung "ich machs halt so und wenn ihr zu blöd seit, es zu lesen,
ist es eure Schuld". In einer Firma mit großen Softwareteams müsste man
sich bald einen anderen Job suchen.
Gerhard schrieb:> Dieser Banalalgortihmus formuliert jemand der mit C umgehen kann> deutlich besser. Es gibt keinerlei Grund, diesen Algorithmus nicht klar> und deutlich hinzuschreiben außer vielleicht die Begründung "ich machs> halt so und wenn ihr zu blöd seit, es zu lesen, ist es eure Schuld". In> einer Firma mit großen Softwareteams müsste man sich bald einen anderen> Job suchen.
So sieht's aus.
Selbsternannte Experten wie der TO ("MISRA und Coding Guidelines kenne
ich zwar, interessiert mich aber nicht"), die glauben, die Genialität
eines Quellcodes hängt ausschließlich reziprok von der Anzahl der
Tastaturanschläge ab, halten es üblicherweise in meinen Teams auch nicht
lange aus. Dazu muss nicht einmal ich die Keule "Entlassungsgrund:
Arbeitsverweigerung durch vorsätzliche Nichteinhaltung einschlägiger
Arbeitsvorschriften" schwingen; üblicherweise reicht schon der Druck der
anderen Teammitglieder, die die Ergüsse des fraglichen Mitarbeiters
verwerten müssen, aus.
Als Hobbyist sage ich auch: Code ist unklar beschrieben und
strukturiert; bevor ich mich hier reindenke, schreibe es lieber selbst
oder nehme eine andere, gut dokumentierte und getestete Funktion (denn
auch das scheint der Autor in seiner Genialität ja nicht zu benötigen).
c-hater schrieb:> Ich muss mich hier nochmal korrigieren. Die wirklich durchdachte> Asm-Umsetzung ist deutlich schneller, deutlich kleiner und immer noch> deutlich besser lesbar...
Apollo liefert zumindest irgendwas, du lieferst nichts, nur Erbrochenes.
MaWin schrieb:> Apollo liefert zumindest irgendwas, du lieferst nichts, nur Erbrochenes.
Die Projekte hier sollen eigentlich den Lesern ein möglichst gutes
Beispiel liefern. Da wäre garkein Beispiel durchaus besser als ein
grottenschlechtes Beispiel.
Mal davon abgesehen frage ich mich, warum dem TO nicht selber folgendes
aufgefallen ist:
Apollo M. schrieb:> *pbuf++ = (val & (d? 1:((typeof(val))1<<(sizeof(val)*8-1))))? '1':'0';
wo er doch zuvor folgendes geschrieben hat:
Apollo M. schrieb:> uint32_t val
Ist das der Hang zur Obfuskation?
W.S.