Hallo zusammen, schon seit langem stört mich, dass meine Fähigkeiten beim Programmieren in C stagnieren. Das ist nicht wirklich verwunderlich. Die meiste Literatur widmet sich entweder abstrakten Konzepten oder ist an Anfänger gerichtet. Eine Umsetzung in der eigenen Sprache wird dann zu einer Sammlung selbst entwickelter Angewohnheiten. Die Profis lernen wohl voneinander. Aber das ist bei Hobbyisten nur schwer möglich. Wie lassen sich "neue" Implementierungstechniken kennenlernen? (Ich habe das "neue" mit Absicht in Klammern gesetzt. Eigentlich interessieren mich bewährte Techniken, auf die ich einfach noch nicht gestoßen bin.) Die GCC Onlinedocs sind nett und ich habe darin schon viele nette Funktionen gefunden. Aber sie behandeln nicht Anwendungsfälle. Es wird wohl auf das Lesen von Quelltext hinauslaufen. Das Problem: Wie findet man guten Quelltext zum Lesen? In Foren o.Ä. findet man ja hauptsächlich Schnipsel und zweifelhafte Fälle. Welchen Quelltext sollte man gelesen haben? Bitte nur Fremd- und keine Eigenprojekte vorschlagen, ansonsten ist eine deutliche Verzerrung zu erwarten. Und bitte auch auf lesbare Teile beschränken. "Der Linux Kernel" ist so groß, dass das keiner lesen kann. Aber überschaubare Teile wären super. Etwas wie "Teil X der OpenSSL2-Bibliothek ist absolut lesenswert, weil da die Behandlung von Puffern mustergültig gelöst wurde". (Bitte den letzten Satz nicht wörtlich nehmen. In Fefes Blog steht gerade etwas zu einem Puffer-Bug und die Suche nach der Stelle im Quelltext war der aktuelle Anlass zur Frage.) Ich habe die Frage mit Absicht in die Rubrik "Mikrocontroller" gestellt. Das ist natürlich die Plattform, die mich am meisten interessiert.
:
Bearbeitet durch User
Hallo, wahrscheinlich nicht ganz das was Du suchst, aber wenn es um AVR Beispiele geht, kannst Du hier bei www.mikrocontroller.net im AVR_Softwarepool schauen. Zur Qualität des Codes kann ich wenig sagen, ist auch von Fall zu Fall unterschiedlich. https://www.mikrocontroller.net/articles/AVR_Softwarepool Ansonsten ist natürlich sehr viel, in unterschiedlicher Qualität, auf github zu finden (26,272 Projekte in C). https://github.com/topics/c?l=c Das kommt der Suche nach der Nadel im Heuhaufen sehr nahe.
Alexander S. schrieb: > wahrscheinlich nicht ganz das was Du suchst, [...] > Zur Qualität des Codes kann ich wenig sagen, [...] > (26,272 Projekte in C). Genau das Problem. Text gibt es viele. Gute Texte finden ist die Schwierigkeit. Und irgendwie will man ja auch vorher um die Qualität des Lesestoffs wissen. Man will sich ja keine schlechten Angewohnheiten abgucken.
:
Bearbeitet durch User
Walter T. schrieb: > Die Profis lernen wohl voneinander. Das ist leider auch nur ein schöner Traum. In der Realität basteln die Profis (also die, die dafür bezahlt werden) auch nur vor sich hin, erfinden jedes Rad neu, tappen in alle schon längst bekannten Stolperfallen, beharren auf ihren selbst ausgedachten Methoden, ... Es gibt keine Kultur des "beim alten Meister lernen" wie im Handwerk, denn dafür ist keine Zeit und Geld. Guter Quellcode ist rar (und jeder hat seine eigenen Kriterien für "gut"), Projekte und Mitarbeiter wechseln häufig, alles muss gestern auf dem Markt sein, und niemand nimmt ohne Zwang Ratschläge von anderen an, weil er es selber besser weiß. Beispiel: Hier Beitrag "Re: C: Viele Funktionen zur Auswahl" wird eine altbekannte Standard-Lösung (Strategy Pattern) für ein Problem genannt welche im Übrigen auch im Informatik-Studium so gelehrt wird, aber sowohl Fragesteller als auch Antwortende verwenden lieber unübliche Eigenbau-Lösungen als dem Profi zu glauben.
Programmierer schrieb: > Hier Beitrag "Re: C: Viele Funktionen zur Auswahl" wird eine > altbekannte Standard-Lösung (Strategy Pattern) für ein Problem genannt > welche im Übrigen auch im Informatik-Studium so gelehrt wird, aber > sowohl Fragesteller als auch Antwortende verwenden lieber unübliche > Eigenbau-Lösungen als dem Profi zu glauben. Nehmen wir doch das Beispiel. Wo fände der Lernwillige denn eine in vollendeter Handwerkskunst implementierte Variante des genannten Pattern, damit er bei der Selbst-Implementierung nicht in die längst bekannten Stolperfallen tappt?
Vielleicht solltest du mal das Buch "Weniger schlecht programmieren" (O'Reily) lesen. Ich persönlich finde das Buch zwar nicht überaus brilliant, aber es enthält doch die ein oder andere wichtige Anregung und Denkanstoß, finde ich.
Wühlhase schrieb: > Ich persönlich finde das Buch zwar nicht überaus brilliant, Das Buch ist gut. Nur wieder: Abstrakte Konzepte. Keine reale Implementierung zum Vergleich. Das ist ein bischen so, wie im 10. Semester Tiefbau zu studieren und niemand lässt einen mal einen Bagger angucken (zu teuer, zu gefährlich), aber ständig wird betont, wie wichtig doch der Praxisbezug sei. Im Gegensatz zu einem für den Heimgebrauch recht kostspieligen Bagger sollten doch gute Quelltexte irgendwie zu bekommen sein.
:
Bearbeitet durch User
Schwer zu sagen was man dir empfehlen kann, weil es nicht zuletzt davon abhängt was du schon kannst. Ich versuche es mal mit https://gforge.inria.fr/frs/download.php/latestfile/5298/ModernC.pdf (gibt es auch als gedrucktes Buch). Ca. 90% dessen was er sagt kann ich unterschreiben. So die ein oder andere Macke hat er aber. Z.B. mag er aus fadenscheinigen Gründen das NULL-Makro nicht. C Signal-Handling mag er auch nicht. Leider gibt er dem Mischen von Namenskonventionen wie z.B. 'size_ofXyz' seinen Segen, statt auf Snake-Case zu bestehen 'size_of_xyz'. Im Großen und Ganzen ist er aber vernünftig.
Du kannst in Erwägung ziehen bei einem Open Source Project deiner Wahl mit zu helfen. Am sinnvollsten suchst du dir eines aus, bei dem du wirklich den Wunsch verspürst etwas beitragen zu wollen. Der Vorteil ist das du dich wirklich in fremde Quellen einarbeiten musst. Und deine eigenen "Pull Requests" werden in der Regel auch quasi mit einem 4 Augen Prinzip geprüft. Ganz zu schweigen das du solche Dinge wie GIT als Versionsverwaltung viel besser kennen lernst. Sowas kann dich sicher mehr Richtung professioneller SW Entwickler schieben.
Ich finde den Source-Code von Chibios lesenswert. Er arbeitet sich mit objektorientiertem C durch sein RTOS. https://osdn.net/projects/chibios/scm/svn/tree/head/trunk/
Hannes J. schrieb: > Ich versuche es mal mit > https://gforge.inria.fr/frs/download.php/latestfile/5298/ModernC.pdf > (gibt es auch als gedrucktes Buch). Ich habe es mal vor Jahren angefangen zu lesen. Für mich wirkte das so, als hätte er seine persönliche C-Standard-Library kommentiert als Buch veröffentlicht. Meine Notizen, was ich vom Buch wirklich mitnehmen konnte, sind leer. (Schlicht: "gelesen") Aber das geht auch alles zu sehr Richtung Bücher. Wo gibt es den echten guten Stoff? Nico T. schrieb: > Ich finde den Source-Code von Chibios lesenswert. Danke, den schaue ich mir mal an. Ich hoffe, dass ich irgendeine echte Applikation finde.
:
Bearbeitet durch User
Walter T. schrieb: > Das Buch ist gut. Nur wieder: Abstrakte Konzepte. Wie willst du Code lesen und verstehen wenn du nicht die in Code umgesetzten, dahinter liegenden abstrakten Konzepte erkennst? Dann ist der Code nur Kauderwelsch für dich. > Das ist ein bischen so, wie im 10. Semester Tiefbau zu studieren und > niemand lässt einen mal einen Bagger angucken (zu teuer, zu gefährlich), > aber ständig wird betont, wie wichtig doch der Praxisbezug sei. Einen Tiefbaustudenten nahe an einen Bagger lassen? Bist du des Wahnsinns? Keine Ausbildung als Baugeräteführer, keinen Baggerschein? Dann sollen die gefälligst Abstand halten.
:
Bearbeitet durch User
Hannes J. schrieb: > Wie willst du Code lesen und verstehen wenn du nicht die in Code > umgesetzten, dahinter liegenden abstrakten Konzepte erkennst? Ein Quellcode, wo die Konzepte sich weder in Variablennamen noch Kommentaren widerspiegeln, ist nicht gut. Blume schrieb: > Du kannst in Erwägung ziehen bei einem Open Source Project deiner Wahl > mit zu helfen. Das Problem: Die Projekte, die mich interessieren, sind größtenteils 1-Mann-Projekte. Woher soll man als Außenstehender wissen, ob der Entwickler gängige Praktiken umsetzt, oder genau wie ich als Einzelperson mangels Vergleich die Sachen so macht, wie er sie macht.
Walter T. schrieb: > Das Problem: Die Projekte, die mich interessieren, sind größtenteils > 1-Mann-Projekte. Woher soll man als Außenstehender wissen, ob der > Entwickler gängige Praktiken umsetzt, oder genau wie ich als > Einzelperson mangels Vergleich die Sachen so macht, wie er sie macht. da hast du Recht um in einem Team mitspielen zu können muss man in einem Team mitspielen wollen. :-)
Walter T. schrieb: > Ein Quellcode, wo die Konzepte sich weder in Variablennamen noch > Kommentaren widerspiegeln, ist nicht gut. Hier mal 2 Konzepte, welche sich nicht an deine Vorstellungen halten: DRY und RAII
Walter T. schrieb: > Ein Quellcode, wo die Konzepte sich weder in Variablennamen noch > Kommentaren widerspiegeln, ist nicht gut. Ach je, der alte Glaube dass man kein Domänenwissen haben muss.
Walter T. schrieb: > Hallo zusammen, > > schon seit langem stört mich, dass meine Fähigkeiten beim Programmieren > in C stagnieren. Das ist nicht wirklich verwunderlich. Die meiste Du wolltest das so: Ist zwar ein bischen alt (Kernel 0.12 Linux), ist aber ueberschaubar (1117p Buch), der Kernel 0.12 sehr kurz. Zhao Jiong, A Heavily Commented Linux Kernel Source Code, nix ISBN, ich habe so etwas gefunden: https://de1lib.org/book/5424495/85d4e2?id=5424495&secret=85d4e2 er hat auch noch ein Follow-Up fuer 0.13 geschrieben, aber mein chinesisch ist aber nicht gut genug :-) Aus dem Preface:
1 | The main goal of this book |
2 | |
3 | The main goal of this book is to use a minimal amount of space or within a limited space to dissect the |
4 | complete Linux kernel source code in order to obtain a full understanding of the basic functions and actual |
5 | implementation of the operating system. To achieve a complete and profound understanding of the Linux kernel, |
6 | a true understanding and introduction of the basic operating principles of the Linux operating system. |
7 | This book's readership is positioned to know the general use of Linux systems or has a certain |
8 | programming basis, but it lacks the basic knowledge to read the current new kernel code and is eager to |
9 | understand the working principle and actual code of the UNIX operating system kernel as soon as possible. |
Es gibt auch noch (wenn man ein wenig googled) Anleitungen, wie man den Kernel dann mit Qemu zu starten bringt. Das ist etwas anspruchsvoll. Gruesse Th.
Walter T. schrieb: > Hallo zusammen, > > schon seit langem stört mich, dass meine Fähigkeiten beim Programmieren > in C stagnieren. Das ist nicht wirklich verwunderlich. Die meiste Ich bin ein wenig bloed: Natuerlich den Tanenbaum, Operating System, design and implementation. Man kann ja zu Minix stehen wie man will, es sind aber fortgeschrittene Lehrbuecher. Und, wie gewuenscht, reines C mit Assembler fuer den Boot. Gruesse Th.
> Operating System, DESIGN and implementation
Ja, ein guteŕ Hinweis.
Heutzutage ist ein Hobbyprogramm umfangreicher als damals ein
Betriebssystem. Ein normales Microcontroller-Projekt hat Webserver und
Wlan. Braucht 20 inkompatible, undurchschaubar komplexe Pakete.
Programmcode eintippen genügt nicht mehr. Auch ein Hobbyprogammierer
muss wissen, wie man umfangreiche, aus mehreren Komponenten
zusammengesetzte Systeme designt.
Angehängte Dateien:
-
20210825_220026.jpg
220 KB
Bitte nicht auf den Standard-Büchern rumreiten. (Leider ist mein Bücherregal in einer etwas zu dunklen Ecke für ein gutes Foto.) Und die Totholz-Teile sind nur eine Auswahl. Viel findet man ja auch im Netz als PDF oder PPT. Oder in der nächstgelegenen Uni-Bibliothek. Ich suche den echten Stoff. Wo man sich auch Idiome abgucken kann. Nur Latein ist eine Sprache, die man komplett aus Büchern lernen kann. Blume schrieb: > Mal ein paar Bücher aus meiner Bibliothek. Kommt in "Clean Coder" noch etwas zur Programmierpraxis, oder geht es da ausschließlich um das Überleben als Softwerker? (Die Leseprobe geht nicht sehr weit.)
:
Bearbeitet durch User
Walter T. schrieb: > Wo fände der Lernwillige denn eine in > vollendeter Handwerkskunst implementierte Variante des genannten > Pattern, damit er bei der Selbst-Implementierung nicht in die längst > bekannten Stolperfallen tappt? Denn Vergleich mit der Vollendeten Handwerkskunst finde ich hier nicht sehr passend. Bei programmieren handelt es sich um ein Handwerk das erst wenige Jahrzehnte alt ist und in dieser Zeit auch nicht unerhebliche Veränderungen erfahren hat und sich quasi noch in einem sehr frühen Stadium seiner Entwicklung befindet. Erschwerend kommt hinzu das es für viele Aufgabenstellungen duzende von Lösungsmöglichkeiten gibt die am Ende alle das machen was sie sollen und somit gleichwertig sind. Ob die jeweilige Lösung "Gut" oder "Schlecht" ist hängt hier eher von persönlichen Vorlieben des Betrachters ab. Was für den Einen super gut ist, ist für den anderen ein Krampf - einfach, weil es seinem persönlichen "Stiel" zuwiderläuft oder entgegenkommt. Am Ende ist es auch oftmals egal solange die geforderte Funktionalität (möglichst Fehlerfrei) gegeben ist und das ganze einigermaßen "lesbar" ist. Etliche Fehler muss man einfach mal selbst gemacht und vor allem auch selbst gesucht haben. Da lernst man am allermeisten dabei:-) Ganz interessant ist mal der umgekehrte Weg. Zu schauen was man möglichst vermeiden soll. Für den Einstieg: - https://de.wikipedia.org/wiki/Anti-Pattern Und mal zum Nachdenken: - https://de.wikipedia.org/wiki/Unix-Philosophie#Pike:_Notes_on_Programming_in_C Ganz interessant ist es auch sich mal die MIRS Dokumente zu Gemüte zu führen. Man darf hier nur nicht den Fehler begehen und versuchen sich Sklavisch dran zu halten (wie bei so vielen anderen Pattern auch). Lesen, Verstehen, im Hinterkopf abspeichern und dann für sich selbst entscheiden was davon sinnvoll ist und was nicht für das was man machen will. So einige wird man erst verstehen und für sinnvoll erachten, wenn man den zugehörigen Fehler mal selbst gemacht und gesucht hat.
Die beste Lektüre fand ich den Quelltext von Xlisp. Das konnte man einfach so locker durchlesen. Alles klar. Aber zum Schluss kam die Frage auf: Hä, wieso kann so ein triviales Programm so eine komplexe Aufgabe erledigen? So einfach aussehende Programme will ich auch schreiben können. Solltest dir Quelltexte suchen, bei denen einer alleine ein umfangreiches System entwickelt hat. Ghostscript, oder Mysql oder so. Und dann herausfinden, wie einer alleine so etwas zustande bringt.
Es wurden ein paar brauchbare Dokumente/Bücher genannt. Aber mal ehrlich: Die kennt doch mittlerweile jeder von uns. Wir wissen um Antipattern, Designphilosophien und Fallen. Auf Konzeptebene. Ich habe am meisten über den konkreten Aufbau von Geräten und Maschinen gelernt, indem ich sie zerlegt, repariert oder einfach mal meine Zeit im Museum genommen habe. Die dahinterstehenden Konzepte kamen aus Büchern oder Vorlesungen. Die Programmiersprache C ist jetzt knapp 50 Jahre alt. Man kann davon ausgehen, dass sie von der Flußphase in die Kriechphase übergegangen ist. Die ersten, die es darin zur Meisterschaft gebracht haben, sind in Rente. Das ist mehr Zeit als zwischen dem Wright Flyer und den ersten zivilen Düsenflugzeugen. Sehr alte Beispiele spiegeln also wohl nicht mehr den Stand der Technik wieder. Ein Projekt als Beispiel zu nehmen, nur weil es populär ist, halte ich auch für kein sinnvolles Unterfangen. Ein Programm ist deswegen populär, weil sein Zweck gebraucht wird, nicht weil es besonders gut programmiert ist. Im Gegenteil würde ich sogar davon ausgehen, dass bei einem sehr nützlichen Projekt auch schlechterer Quelltext durchgeht, wenn der Nutzen stimmt. Anscheinend lesen Softwareentwickler nicht gern Quelltext. Das unterscheidet sie von den Ingenieuren. Einen guten Schaltplan oder gute technische Zeichnungen oder Dokumentationen oder ein gut gelungenes Leiterplattenlayout, eine gelungene Brückenkonstruktion usw. kann man auch anlasslos interessehalber durchgehen. Bei Quelltext scheint das anders zu sein. Also entweder mögen die Softwerker ihre Arbeit nicht, oder sie finden grundsätzlich die Arbeit anderer häßlich. Was mir am ChibiOS-Beispiel gefällt: Die Dokumentierung der Einzelfunktionen mit Doxygen ist in den Teilen, die ich mir bis jetzt angeguckt habe, absolut mustergültig. Da wurde Energie reingesteckt und da kann man sich etwas abgucken. Besonders interessante Funktionen oder Funktionalitäten habe ich noch nicht entdeckt, aber auch noch nicht viel Zeit hineingesteckt, da ich die Architektur-Doku noch nicht gefunden habe.
:
Bearbeitet durch User
Der Opa aus der Muppet Show schrieb: > Die beste Lektüre fand ich den Quelltext von Xlisp Tja, damals. Quelltexte von CP/M, GEM und Windows waren nicht nur kommerziell erfolgreiche Programme, sondern auch gute lehrreiche Quelltexte, statt akademischem Furz sah man dort wie man es richtig macht. Leider alles aus der vor-OOP Zeit, bei CP/M gar aus der Vor-C Ära in PL/M. Heute gibt es 'Patterns' als Muster zum Abscheiben ohne denken.
Walter T. schrieb: > Anscheinend lesen Softwareentwickler nicht gern Quelltext. Das > unterscheidet sie von den Ingenieuren Quelltexte sind eben auch viele Größenordnungen komplexer als so ein gewöhnlicher Schaltplan und nicht so schön visuell erfassbar. So ein Schemabild einer elektrochemischen Anlage ist vielleicht eine Din-a-3-Seite groß, der Schaltplan der zugehörigen Steuereinheit vielleicht 10 Din-a-4-Seiten, da kann man sich innerhalb von ein paar Stunden durchwühlen, und es ist sehr leicht erfassbar was zusammen gehört und wo funktionale Einheiten sind. Der dazugehörige Sourcecode ist lang genug um den Leser wochenlang zu beschäftigen und natürlich so verworren, dass man sehr detektivisch vorgehen muss um die Zusammenhänge zu erkennen. Keine besonders erbauliche Tätigkeit. Walter T. schrieb: > oder sie finden grundsätzlich die Arbeit anderer häßlich. Das sowieso immer. Walter T. schrieb: > da ich die Architektur-Doku noch nicht gefunden > habe. Der Knackpunkt: Architektur-Doku wäre viel wichtiger als Doxygen-Doku der einzelnen Funktionen. Die Signatur der Funktionen sollte sie praktisch selbsterklärend machen und Kommentare oft überflüssig (klappt natürlich mit C-Code weniger gut, wo alles void* oder int ist), aber ein guter Überblick ist essentiell. MaWin schrieb: > statt akademischem Furz sah man dort wie man es richtig > macht. Leider alles aus der vor-OOP Zeit, bei CP/M gar aus der Vor-C Ära > in PL/M. Heute gibt es 'Patterns' als Muster zum Abscheiben ohne denken. Hier das nächste Musterbeispiel - die über Jahrzehnte gewonnenen Erkenntnisse von Experten werden abgelehnt. Das weiß man schließlich selbst besser! Walter T. schrieb: > Wo fände der Lernwillige denn eine in > vollendeter Handwerkskunst implementierte Variante des genannten > Pattern ISBN 978-0201633610 Das Strategy-Pattern ist aber nicht sehr komplex, das gezeigte Codebeispiel ist hier schon ziemlich ausreichend. Was tatsächlich ziemlich hilfreich ist um auf aktuellen Stand der Technik zu kommen und fortgeschrittene Techniken zu lernen sind die IRC/Slack-Channel zu C++. Dort sind viele "Szenegrößen" anzutreffen. Leider muss man hier mit dem üblichen Alt-Right-Mindset der US-Amerikanischen Hackerkultur zurecht kommen. Die Includecpp-Channel könnten eine Alternative sein.
Walter T. schrieb: > schon seit langem stört mich, dass meine Fähigkeiten beim Programmieren > in C stagnieren. Programmieren kann man nicht auswendig lernen, wie eine Fremdsprache oder ein Gesetzbuch. Man muß lernen, in Abläufen zu denken, d.h. das Problem in einzelne Schritte umzuformen. Das Erstellen eines Programmablaufplanes erleichtert dann das Coden erheblich. Diesen Programmablaufplan kann man dann auch erstmal logisch überprüfen, ehe man Code einhackt. Ich benutze abwechselnd Top-down und Bottom-up. D.h. wenn es in der einen Richtung hakt, nähere ich mich von der anderen Seite an. Das eigentlich Code einhacken sehe ich als nebensächlich an. Wenn erstmal der Ablauf klar ist, ergibts sich das von alleine. Das ist nur Übung. Viele Anfänger meinen, man könne einfach so drauflos hacken. Aber das ist eine Sackgasse, dabei lernt man nichts oder nur sehr sehr langsam. Auch fremden Code anschauen bringt nichts, solange man nicht den zugrunde liegenden Ablauf verstanden hat. Als Anfänger sollte man daher über jede Funktion einen Kommentar schreiben, wie sie funktioniert.
Programmierer schrieb: > Der Knackpunkt: Architektur-Doku wäre viel wichtiger als Doxygen-Doku > der einzelnen Funktionen. Und wenn das Projekt gut ist, ist die auch irgendwo. Wenn nicht, ist das ein brauchbares Beispiel für eine Schieflage (falsche Prioritäten). Peter D. schrieb: > Programmieren kann man nicht auswendig lernen, wie eine Fremdsprache > oder ein Gesetzbuch. Auch Fremdsprachen lernt man nicht auswendig. Im Gegenteil. Beherrschen erfordert eine Denkweise in Kontexten und (Argumentations-)Strukturen. Dazu kommen jede Menge Erfahrungswerte, in welchen Kontexten welche Idiome passend sind. Zwei Beispiele: _countof() habe ich gestern kennengelernt und darüber auf die GCC-Variante ARRAY_SIZE(). Vorher habe ich bei jedem Funtionsaufruf ein selbstgebasteltes Makro genutzt, das genau das Gleiche macht. Kennt man das Idiom, kann man es nutzen. Ansonten schreibt man seinen eigenen Kram. Das Idiom !!a, um einer Variable einen booleschen Wert zu nutzen, der garaniert 1 ist, habe ich auch erst vor ein paar Jahren durch Zufall kennengelernt. Vorher hatte ich einen etwas umständlicheren Ausdruck (a>0) für unsigned und (a!=0) für signed Variablen für den gleichen Zweck genutzt. Ich bin sehr sicher, dass von denen die diese Idiome nutzen, weniger als 20% sich das selbst genauso ausgedacht oder gezielt danach gesucht und 80% das durch Zufall aufgeschnappt haben. Aber kennt und nutzt man die Idiome, wird ein Quelltext für jeden, der es auch kennt, direkt besser lesbar. Peter D. schrieb: > Viele Anfänger meinen, man könne einfach so drauflos hacken. Aber das > ist eine Sackgasse, dabei lernt man nichts oder nur sehr sehr langsam. Aus dem Anfängerkram sind wir doch schon lange draußen, oder? Man kann ihn mal irgendwann begraben sein lassen.
Wäre das was für dich? https://edutechlearners.com/download/Introduction_to_algorithms-3rd%20Edition.pdf https://link.springer.com/book/10.1007/978-3-540-76394-9 (( https://www.tu-ilmenau.de/universitaet/fakultaeten/fakultaet-informatik-und-automatisierung/profil/institute-und-fachgebiete/institut-fuer-theoretische-informatik/fachgebiet-komplexitaetstheorie-und-effiziente-algorithmen/team/prof-m-dietzfelbinger/taschenbuch-der-algorithmen ))
Walter T. schrieb: > Das Idiom !!a ... (a!=0) Sowas würde ich unter Mikrooptimierung einordnen, die Lesbarkeit unterscheidet sich kaum. Als Anfänger sollte man Mikrooptimierung vermeiden, die Lesbarkeit und Funktion haben absoluten Vorrang. Lösungsansätze sollten daher nicht zu komplex sein. > (a>0) Würde ich vermeiden, da es typabhängig reagiert und hier auch nicht notwendig ist. Walter T. schrieb: > _countof() Kannte ich bisher auch nicht. In den seltenen Fällen, wo man sowas braucht, habe ich es ausgeschrieben. In der Regel nehme ich ein Define für die Arraysize oder einen Leerstring als Endezeichen.
Walter T. schrieb: > _countof() habe ich gestern kennengelernt und darüber auf die > GCC-Variante ARRAY_SIZE(). Vorher habe ich bei jedem Funtionsaufruf ein > selbstgebasteltes Makro genutzt, das genau das Gleiche macht. In C++ schreibt man std::size(myArray). Funktioniert mit jedem Compiler direkt und unproblematisch, und sogar dann noch wenn man den Typ von myArray auf eine Container-Klasse ändert. Walter T. schrieb: > Das Idiom !!a, um einer Variable einen booleschen Wert zu nutzen, der > garaniert 1 ist, habe ich auch erst vor ein paar Jahren durch Zufall > kennengelernt Mache ich quasi nie, weil dieser Fall sowieso selten auftritt. "!= 0" finde ich genau so gut.
Walter T. schrieb: > Wühlhase schrieb: >> Ich persönlich finde das Buch zwar nicht überaus brilliant, > > Das Buch ist gut. Nur wieder: Abstrakte Konzepte. Keine reale > Implementierung zum Vergleich. Du kennst das Buch nicht, denke ich. Das, was da besprochen wird, hat mit praktischer Implementierung wenig zu tun. (Was nicht bedeutet, daß es keinen praktischen Nutzen hat.) Walter T. schrieb: > Das ist ein bischen so, wie im 10. Semester Tiefbau zu studieren und > niemand lässt einen mal einen Bagger angucken (zu teuer, zu gefährlich), > aber ständig wird betont, wie wichtig doch der Praxisbezug sei. > > Im Gegensatz zu einem für den Heimgebrauch recht kostspieligen Bagger > sollten doch gute Quelltexte irgendwie zu bekommen sein. Du solltest vielleicht mal über den Unterschied zwischen Lehre und Studium sinnieren. Du willst etwas Neues lernen - das ist ok. Du erwartest aber anscheinen an einem Punkt Anleitung, wo jedem anderen eine abstrakte Abhandlung reicht und er sich dann alleine auf den Weg macht (und dabei seinen eigenen Stil entwickelt). Walter T. schrieb: > Anscheinend lesen Softwareentwickler nicht gern Quelltext. Das > unterscheidet sie von den Ingenieuren. Einen guten Schaltplan oder gute > technische Zeichnungen oder Dokumentationen oder ein gut gelungenes > Leiterplattenlayout, eine gelungene Brückenkonstruktion usw. kann man > auch anlasslos interessehalber durchgehen. Bei Quelltext scheint das > anders zu sein. Also entweder mögen die Softwerker ihre Arbeit nicht, > oder sie finden grundsätzlich die Arbeit anderer häßlich. Ich habe mir ziemlich viele Gedanken über meinen Schaltplan- und Layoutstil gemacht und ich denke, ich bin da bisher zu recht brauchbaren Ergebnissen gekommen. Ich habe allerdings noch nie auch nur einen einzigen Beispielschaltplan von anderen gesucht, um da etwas zu lernen. Weitaus nützlicher fand ich da ein paar Fachgespräche mit Kollegen, oder auch den ein oder anderen Thread hier. Plus ein paar abscheulich abschreckender Beispiele in Datenblättern oder Application Notes, die mir zufällig bei der Arbeit über den Weg gelaufen kamen. Am meisten habe ich aber durch selber denken gelernt. Was will ich und wie erreiche ich es, was will ich auf keinen Fall und wie vermeide ich es? Plus Ausprobieren -> Erfahrungsgewinn. Und so machen das Softwareentwickler auch.
Wühlhase schrieb: > Du erwartest aber anscheinen an einem Punkt Anleitung, Ich suche keine Anleitung. Ich suche guten Quelltext. Wenn ich eine Fremdsprache lerne und über das Volkshochschulniveau hinaus bin, nutze ich a) Literatur über die Sprache b) Literatur in der Sprache auf bekannter Niveauebene. c) Versuche in der Sprache zu hören d) und in der Sprache zu sprechen. Aus irgendeinem Grund finden hier alle die Punkte b) und c) absurd und beschränken sich auf a) und d). Ihr wollt sprechen aber nicht zuhören und wundert euch, dass euch keiner zuhört. Kein Wunder, dass ihr allgemein als komisch angesehen werdet. Für b) und c) braucht man Material mit bekanntem (und hoffentlich hohem Niveau). Bei Schriftmaterial ist da die Auflage ein guter Indikator, wenn man das noch nicht selbst beurteilen kann. Aber meist verlässt man sich auf Empfehlungen.
:
Bearbeitet durch User
Die Qualität von Quelltext wird selten bewertet. Wenn es getan wird, dann meistens nach schmerzhaften Problemen. Deswegen dürfte es schwierig sein, auf öffentlich zugängliche Quelltexte zu stoßen, deren Qualität als gut oder sehr gut gewertet wurde. Es gibt Firmen, die so etwas als Service anbieten, doch das passiert nach keiner Erfahrung eher hinter verschlossenen Türen. Die Quelltexte die mir üblicherweise anschaue, sind halt so wie sie sind. Meine Meinung dazu interessiert keinen und andere tun ihre Meinung dazu auch nur selten Kund.
Hi, ich kann dir leider nur Basics empfehlen: Books written by Michael J. Pont: hier geht es um 'Time Triggert Scheduling', echt harter Stoff. Aber sehr cool. Design Patterns: hier kann ich dir 'adamtornhill' empfehlen, er zeigt einige Lösungen in C. super gemacht. nicht ganz so schwerer Stoff.
Alles was ich tagsüber ins Repo einchecke wird nach code guidelines überprüft, die entsprechende Email liegt mir Tags drauf vor was alles nicht regelkonform und was alles gefixt ist. Ein Account bei z.B. O'REILLY eröffnet einem Zugriff auf Lesestoff der 10 Jahre Lockdown locker füllt. Und guten Quelltext (also meiner) darf ich nicht veröffentlichen weil Firmeneigentum :-)
Walter T. schrieb: > Bitte nicht auf den Standard-Büchern rumreiten. Zur Handwerklichen Qualität fehlen dort die Klassiker "Code Complete" und "Writing Solid Code". Pattern oder Algorithmen sind praktisch nur zielgerichtet sinnvoll. Z.B. wenn Du ein RTOS schreiben oder verbessern willst. Oder Suchalgorithmen. Genauso wichtig ist es aber auch, sich mit den Eigenschaften typischer Ausdrucksformen zu beschäftigen.
Walter T. schrieb: > Ich suche keine Anleitung. Nein? Ein Fehler! Mein Rat: Lerne die üblichen "Design Pattern". Die findest du in Büchern. Dann übe. Spiele damit, bis sie sitzen. Walter T. schrieb: > Ich suche guten Quelltext. Quelltexte anderer Leute, haben eine gewisse Ähnlichkeit mit einem Sack voll ungewaschener Unterhosen fremder Leute. Da finden sich gerne auch reichlich braune Streifen und sonstiges Zeug, mit dem man eigentlich nix zu tun haben will.
EAF schrieb: > Quelltexte anderer Leute, haben eine gewisse Ähnlichkeit mit einem Sack > voll ungewaschener Unterhosen fremder Leute. > Da finden sich gerne auch reichlich braune Streifen und sonstiges Zeug, > mit dem man eigentlich nix zu tun haben will. Wenn das stimmt, lässt das nur zwei mögliche Schlüsse zu: Entweder kann niemand sauber programmieren oder Softwareentwickler hassen einander so, dass sie niemals die Leistung eines anderen anerkennen würden. Nach momentanem Stand würde ich vermuten, dass beides zutrifft.
Walter T. schrieb: > Das Idiom !!a, um einer Variable einen booleschen Wert zu nutzen, der > garaniert 1 ist, habe ich auch erst vor ein paar Jahren durch Zufall > kennengelernt. Sowas finde ich nun wiederum völlig unleserlich und würde es deshalb vermeiden. In "modernem" (≥ C99) C würde ich, wenn man das unbedingt braucht, lieber eine bool-Zwischenvariable schreiben:
1 | #include <stdbool.h> |
2 | |
3 | bool foo = (bool)a; |
Die hat dann auch garantiert die Werte 0 oder 1 und sonst nichts. Da siehst du schon: sehr vieles ist auch einfach Geschmackssache. Aus ähnlichen Lesbarkeitsgründen mag ich auch diese "verkehrt herum geschriebenen" Vergleiche nicht:
1 | if (42 == foo) { |
2 | // mach was
|
3 | }
|
Der Sinn der Sache war ja mal, dass man versehentlich geschriebene einfache Gleichheitszeichen im Vergleich sicher angemosert bekommt. Allerdings widerspricht diese Reihenfolge m.M.n. komplett unserem üblichen Lesefluss, denn man fragt ja "ist foo gleich 42?" und nicht "sind 42 und foo gerade gleich?". Compiler mosern das einfache Gleichheitszeichen im Vergleich sowieso seit mindestens 25 Jahren sauber an, und der ganze Zirkus funktioniert gleich gar nicht mehr, wenn man zwei Variablen miteinander vergleichen möchte.
Jörg W. schrieb: > Da siehst du schon: sehr vieles ist auch einfach Geschmackssache. Da stimme ich Dir uneingeschränkt zu. Jörg W. schrieb: > Sowas finde ich nun wiederum völlig unleserlich und würde es deshalb > vermeiden. Ich mag die mittlerweile, um Bitmasken zu füllen. Es sind eben drei Zeichen weniger als (a!=0), so dass die Zeilen nicht zu lang werden und haben einen hohen Wiedererkennungswert. Ich will aber auch gar nicht behaupten, dass man die Idiome mögen muss. Aber bevor man sie nicht mögen kann, muss man sie erst einmal kennen. Ich wähle lieber eine Variante aus, weil sie die beste von dreien ist, die mir einfallen, als weil sie die einzige ist, die ich kenne.
NichtWichtig schrieb: > Und guten Quelltext (also meiner) darf ich nicht veröffentlichen weil > Firmeneigentum :-) Schreibst auch nur für die Firma, wahr?
Robert Martin mit seinem "Clean Code" scheint ein richtiger Profi zu sein. Wo findet man denn seine Programme und seinen Quellcode? Oder hat er auch nur geheimen Programmcode für seine Arbeitgeber geschrieben? ;-)
Walter T. schrieb: > Es sind eben drei Zeichen weniger als (a!=0) Es sind fünf Zeichen weniger als ordentlich geschriebene (a != 0). :-) Für solche Sachen finde ich Makros ganz praktisch, auch wenn man ansonsten vielleicht mit Makros eher sparsam sein sollte:
1 | #define B(x) ((x) != 0) // guarantees either 0 or 1
|
2 | |
3 | ...
|
4 | |
5 | (B(a) << 4) | B(b); |
6 | |
7 | #undef B
|
Wenn man eh einen Makro nimmt, kann man dann aber auch gleich die Schiebeweite mit einbauen:
1 | #define BIT(x, m) (((x) != 0) << (m))
|
2 | |
3 | ...
|
4 | BIT(a, 4) | BIT(b, 0); |
5 | |
6 | #undef BIT
|
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Für solche Sachen finde ich Makros ganz praktisch Noch besser sind inline-Funktionen, weil Makros, insbesondere bei so kurzen Namen, diverse Nachteile haben (Scope, Typ). Wenn mir hier jetzt sofort widersprochen wird: Noch ein Fall von "Bloß nicht die etablierten von erfahrenen Profis erarbeiteten Methoden anwenden".
Jörg W. schrieb: > #define BIT(x, m) (((x) != 0) << (m)) > ... > BIT(a, 4) | BIT(b, 0); > #undef BIT
1 | #define BIT(x, m) (((x) != 0) << (m))
|
2 | |
3 | ...
|
4 | |
5 | BIT(a, 4) | BIT(b, 0); |
6 | ...
|
7 | #undef BIT
|
vs.
1 | (!!a)<<4 | (!!b)<<0 |
Also da haben wir sicherlich nicht den gleichen Geschmack, was das kleinere Übel ist.
Programmierer schrieb: > Noch besser sind inline-Funktionen, weil Makros, insbesondere bei so > kurzen Namen, diverse Nachteile haben (Scope, Typ). Beides ist für den Anwendungsfall allerdings überschaubar, und damit man damit keinen Missbrauch treiben kann, habe ich absichtlich auch das abschließende #undef angedeutet. **Das** geht mit einer inline-Funktion nicht. ;-)
Walter T. schrieb: > Wenn das stimmt, lässt das nur zwei mögliche Schlüsse zu: Entweder kann > niemand sauber programmieren oder Softwareentwickler hassen einander so, > dass sie niemals die Leistung eines anderen anerkennen würden. Alles klar! Keine Fragen mehr.....
Walter T. schrieb: > (!!a)<<4 | (!!b)<<0 > > Also da haben wir sicherlich nicht den gleichen Geschmack, was das > kleinere Übel ist. Ja, schon deshalb, weil ich für den Vorrang der Operatorenreihenfolge zwischen | und << ins Buch schauen müsste, und immer, wenn sowas passiert, sollte man lieber Klammern schreiben. Wenn du jetzt noch die üblichen Leerzeichen um << einfügst, dann sieht das so aus:
1 | BIT(a, 4) | BIT(b, 0); |
2 | |
3 | ((!!a) << 4) | ((!!b) << 0); |
Die Klammern um die unären Operatoren sind allerdings überflüssig, denn unäre Operatoren haben immer höhere Priorität als binäre. Diese Regel kann ich mir auch ohne Buch merken. ;-) Allerdings steht es dir natürlich frei, wenn der Platz wirklich knapp ist, den etwas erklärenderen Namen wie "BIT" dann einfach zu "B" einzukürzen:
1 | B(a, 4) | B(b, 0); |
Daher ja dann das #undef B.
:
Bearbeitet durch Moderator
Vielleicht finde ich die Makro-Lösung im passenden Kontext auch sinnvoller. Wer weis. Forenschnipsel sind eben kontext-frei und bei vielen Sachen bleibt der Nutzen zweifelhaft. Womit wir wieder beim Eröffnungspunkt wären. Ein ähnlicher Zweifelpunkt ist die klassische Frage: Viel Scrollarbeit durch lange Funktionen, oder noch mehr Scrollarbeit durch viele kurze Funktionen. Ich kenne nur die Variante, die ich wähle. Vielleicht ist es besser, wie andere das machen.
:
Bearbeitet durch User
Walter T. schrieb: > noch mehr Scrollarbeit durch viele kurze Funktionen Ist definitiv der von Profis präferierte Stil. Durch Aufteilung auf mehr Dateien braucht man auch nicht so viel scrollen. Viele kleine leicht verständliche Funktionen zu einem großen Ganzen zu kombinieren ist wesentlich wartbarer und auch leichter zu testen. Das ist natürlich nie 100% umsetzbar, aber die richtige Richtung.
Walter T. schrieb: > Vielleicht ist es > besser, wie andere das machen. "Besser" ist vom Kontext abhängig. So wie es für "gut" und "böse" auch ist. Zudem: Steige um auf C++! Da gibts auch viele "neue" Konzepte zu lernen.
Programmierer schrieb: > Walter T. schrieb: >> noch mehr Scrollarbeit durch viele kurze Funktionen > > Ist definitiv der von Profis präferierte Stil. Das ist aber nicht das einzige Dilemma. Es gibt dutzende von Alltagsdilemmata, die ständig auftauchen, auch wenn mir gerade nur zehn einfallen: - Viele Funktionen, die ungefähr etwas ähnliches machen, oder wenige Funktionen mit ellenlangen Parameterlisten? - Ellenlange Funktionsaufrufe oder viele Zwischenvariablen? - Der dicke Master Control Blob oder eine Ansammlung eng verknüpfter voneinander abhängiger Funktionen? - Das große struct, in dem viele Funktionen herumschreiben, oder viele lokale Variablen? - Fehlerbehandlung durch den Aufrufer oder den Aufgerufenen? Wie werden Fehler signalisiert und wie behandelt? - Parameterlisten fcn(In1, In2, *Out) oder fnc(*Out, In1, In2) (__builtin_add_overflow() vs. memcpy() )? - Nur intern verwendete Structs voll sichtbar definieren und in den Variablenraum der aufrufenden Funktion, oder verstecken und malloc() *)? - Funktionen mit vielen Parametern oder mit Struct-Parametern? - Konfiguration per Header oder per Build-Parameter? - Endmarker oder Längenvariable *)? - Behandlung von n+1-Fehlern: Prüfende Codeabschnitte (mit Laufzeit-Overhead) oder Verantwortung auf den Aufrufer abwälzen? *) Entfällt bei C++&Co größtenteils.
:
Bearbeitet durch User
Walter T. schrieb: > - Viele Funktionen, die ungefähr etwas ähnliches machen, oder wenige > Funktionen mit ellenlangen Parameterlisten? Von Fall zu Fall entscheiden. > - Ellenlange Funktionsaufrufe oder viele Zwischenvariablen? Zwischenvariablen erleichtern sehr oft das Verständnis. Heutige Compiler optimieren sowas sowieso weg, außer bissel Schreibarbeit kosten die also nichts (sofern du nicht gerade mit -O0 compilierst, aber das würde ich persönlich nicht einmal für Debug-Code tun). > - Der dicke Master Control Blob oder eine Ansammlung eng verknüpfter > voneinander abhängiger Funktionen? Verstehe ich nicht. > - Das große struct, in dem viele Funktionen herumschreiben, oder viele > lokale Variablen? So lokal wie möglich. > - Fehlerbehandlung durch den Aufrufer oder den Aufgerufenen? Wie werden > Fehler signalisiert und wie behandelt? Vor allem konsistent, nicht mal so, mal so. > - Parameterlisten fcn(In1, In2, *Out) oder fnc(*Out, In1, In2) > (__builtin_add_overflow() vs. memcpy() )? Geschmackssache. Wiederum: möglichst einheitlich ist wichtiger als das konkrete "wie herum". > - Nur intern verwendete Structs voll sichtbar definieren und in den > Variablenraum der aufrufenden Funktion, oder verstecken und malloc() *)? Je weniger nach außen dringt, um so einfacher ist es überschau- und bei Bedarf änderbar. > - Funktionen mit vielen Parametern oder mit Struct-Parametern? Oftmals auch Geschmackssache. > - Konfiguration per Header oder per Build-Parameter? Hauptsache nicht gemischt. > - Endmarker oder Längenvariable *)? Hängt vom konkreten Fall ab. > - Behandlung von n+1-Fehlern: Prüfende Codeabschnitte (mit > Laufzeit-Overhead) oder Verantwortung auf den Aufrufer abwälzen? Hängt davon ab, ob du dem Aufrufer vertrauen kannst. Eine Bibliotheksfunktion sollte daher prüfen, irgendwelche projektinternen Funktionen können sich auf bereits vorgenommene Prüfungen verlassen, aber man tut gut daran, dass irgendwo am Anfang der Funktion auch so zu dokumentieren ("Diese Funktion kann nur von foo() oder bar() aus aufgerufen werden, die garantieren, dass Bedingung X eingehalten wird.")
Jörg W. schrieb: > [...] aber man tut gut daran, dass irgendwo am Anfang der Funktion auch so zu > dokumentieren ("Diese Funktion kann nur von foo() oder bar() aus > aufgerufen werden, die garantieren, dass Bedingung X eingehalten wird.") Auch so ein Fall: Nur dokumentieren oder erzwingen? Jörg W. schrieb: > Von Fall zu Fall entscheiden. So würde ich jede der Fragen beantworten. Unter anderem deswegen interessiert mich ja guter Quelltext anderer Leute: Wie solche Abwägungen im konkreten Fall getroffen wurden. Die Beweggründe lassen sich aus Quelltext natürlich nur schwer lesen, wenn sie nicht sehr explizit kommentiert sind, aber wenig ist besser als nichts.
:
Bearbeitet durch User
Walter T. schrieb: > Auch so ein Fall: Nur dokumentieren oder erzwingen? Wie willst du erzwingen, dass eine Funktion nur von "bekannt guten" gerufen wird? Zusätzliche Tests innerhalb einer Funktion kosten halt sehr sicher zusätzliche Zeit. Wenn ich mir sicher sein kann, dass der Aufrufer den Test bereits gemacht hat, dann lass ich sowas weg, aber dokumentiere, dass ich mich drauf verlasse an dieser Stelle. Bei einer Bibliotheksfunktion, die "irgendjemand" aufrufen kann, ist das anders. Auch da kann (und sollte) man natürlich dokumentieren, auf was man sich bereits verlässt. Auf beiden Seiten zu testen bringt in aller Regel einen Performancenachteil. Wenn das API einer Funktion einen bestimmten Test bereits garantiert, dann muss der Aufrufer ihn nicht ausführen. Sowas ist daher Quatsch:
1 | if (p != NULL) |
2 | free(p); |
Das API von free() (sofern es sich um eine standarkonforme Implementierung handelt) garantiert nämlich, dass im Falle eines Nullzeigers keine Aktion erfolgt.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Wie willst du erzwingen, dass eine Funktion nur von "bekannt guten" > gerufen wird? Erst gar nicht exportieren (Library) oder "static" auf Quelltext-Ebene oder zumindest nur in einem "private"-Header. Jörg W. schrieb: > Sowas > ist daher Quatsch: > if (p != NULL) > free(p); > > Das API von free() (sofern es sich um eine standarkonforme > Implementierung handelt) garantiert nämlich, dass im Falle eines > Nullzeigers keine Aktion erfolgt. Auch das hätte ich völlig anders herum gesehen. Meine Denkweise wäre gewesen: "Wenn die Implementierung standardkonform ist, wird die doppelte Prüfung wegoptimiert, weil der Compiler in einer hosted environment seine C-Lib-Funktionen ja kennt. Und wenn nicht, ist die Prüfung jetzt da. In jedem Fall erspart mir das aber, bei der nächsten Fehlersuche in die Doku zu gucken, was von beidem zutrifft, und nicht bei der nächsen Fehlersuche oder beim nächsten Lesen hier hängenzubleiben." Ich glaube, mehr als die Hälfte aller Klammern, die ich setze, sind aus ähnlichen Erwägungen. Welche Abwägung jetzt besser ist, ist diskutabel. Wahrscheinlich Deine, weil Du mehr Erfahrung hast. Aber beide kennen ist nie verkehrt. Die folgende Aussage in Fefes Blog war der Anlass für den Thread: " Update: Ich muss an der Stelle meiner Enttäuschung ein bisschen Luft machen. Dieser SM2-Bug ... es gibt da ein beliebtes Muster, wie man Funktionen aufbaut, die variabel viel Daten zurückgeben. Entweder die Funktion gibt einen frisch allozierten Puffer zurück. Das ist am einfachsten, aber aus irgendwelchen Gründen unpopulär. Daher hat sich das populäre Muster herausgearbeitet, dass du die Funktion zweimal aufrufst. Das erste Mal mit einem ungültigen Zielpuffer, dann sagt er dir, wieviel Platz er im Puffer braucht. Dann holst du dir einen Puffer in der Größe und rufst es nochmal auf. " Ich hatte dieses Pattern nie vorher in freier Wildbahn gesehen. Was aber eben auch daran liegt, selten in der freien Wildbahn zu sein. Aber ich habe auch noch nie mit einer Library gearbeitet, die so angesprochen werden wollte. Ich kenne Libraries, die einen Zeiger auf das malloc() meiner Wahl haben wollten und andere, die irgendeine Form von getsize()-Funktion hatten.
:
Bearbeitet durch User
Ich hatte damals ein Open-Source Projekt gestartet, das reges Interesse fand. Da bekam ich von anderen Entwicklern eine Menge Feedback mit Verbesserungsvorschlägen, sowohl was den Stil angeht als auch fachliche Aspekte. Da es schon so viele gibt wird es immer schwieriger ein neues Projekt zu starten für das sich auch andere interessieren. Aber es gibt immer wieder mal bestehende Projekte die nach Mitmachern suchen - vor allem zum Aufräumen von Altlasten.
Stefan ⛄ F. schrieb: > Aber es gibt immer > wieder mal bestehende Projekte die nach Mitmachern suchen - vor allem > zum Aufräumen von Altlasten. Wie Altlasten aussehen, weiß ich ja. Habe ich ja selbst. Wie soll man Altlasten beseitigen, wenn man noch nie gesehen hat, wie es in richtig aussieht?
Walter T. schrieb: > Wie Altlasten aussehen, weiß ich ja. Habe ich ja selbst. Wie soll man > Altlasten beseitigen, wenn man noch nie gesehen hat, wie es in richtig > aussieht? Dabei helfen die dann die anderen Projektmitglieder. So etwas lernt man kontinuierlich über Jahre hinweg - eigentlich bis zum Ruhestand.
Stefan ⛄ F. schrieb: > Walter T. schrieb: >> Wie Altlasten aussehen, weiß ich ja. Habe ich ja selbst. Wie soll man >> Altlasten beseitigen, wenn man noch nie gesehen hat, wie es in richtig >> aussieht? > > Dabei helfen die dann die anderen Projektmitglieder. Und woher weiß ich, dass die das wissen? Es ist ja nicht so, als hätten sie ein sauberes Projekt als Referenz vorzuweisen.
Walter T. schrieb: > Und woher weiß ich, dass die das wissen? Es ist ja nicht so, als hätten > sie ein sauberes Projekt als Referenz vorzuweisen. Das Team bestimmt, was "sauber" ist und was nicht. Jedes Team und jedes Projekt hat andere Ansprüche. Sie ändern sich ständig. Deswegen ist es problematisch, solche Anweisungen als Buch fest zu halten. Bücher mit den Worten "Patterns" und "Kochbuch" im Titel sind da auf einem sinnvollen Level. Der Rest ergibt sich in den Projekt-Teams. Alleine lernt man so etwas 10x langsamer als im Team. Und im Team ist es schon ein nie endender Lernprozess der bis zu Ruhestand andauert.
Walter T. schrieb: > Wie Altlasten aussehen, weiß ich ja. Habe ich ja selbst. Wie soll man > Altlasten beseitigen, wenn man noch nie gesehen hat, wie es in richtig > aussieht? Du irrst ganz fürchterlich! Wenn du meinst, du könntest aus anderer Leuten Unterhosen ablesen, was es Morgen zu Mittag gibt. Vergiss es! Lerne einfach, wie man es richtig tut, stehe zu deinen Lücken, und werde glücklich.
Stefan ⛄ F. schrieb: > Und im Team ist es > schon ein nie endender Lernprozess der bis zu Ruhestand andauert. Na toll. Die Empfehlung lautet dann also, solche Diskussionen für den Rest des Lebens ständig zu führen. Ich kann mir nur sehr schwer eine noch unerquicklichere Freizeitbeschäftigung vorstellen. Im Verhältnis dazu ist es wahrscheinlich sogar angenehm, sich nach Feierabend gegen Geld ordentlich auspeitschen zu lassen.
:
Bearbeitet durch User
Walter T. schrieb: > Na toll. Die Empfehlung lautet dann also, solche Diskussionen für den > Rest des Lebens ständig zu führen. Ja > Ich kann mir nur sehr schwer eine noch > unerquicklichere Freizeitbeschäftigung vorstellen. Ich werde für das Diskutieren bezahlt. Aber ja, eine klare Trennung zwischen Freizeit und Beruf gibt es in meinem Umfeld bei keinem guten Softwareentwickler. Das machen nur die Looser, die nirgendwo länger als 6 Monate bleiben. Für Softwareentwickler ist es auch selbstverständlich, sich zu einem wesentlichen Anteil während der Freizeit for zu bilden, und zwar auf eigene Kosten. Wer Abends um 17:00 abschalten will, der sollte sich besser einen anderen Job suchen. Nenne es ruhig "Scheiß Job". Je weniger Leute ihn machen wollen, umso besser für mich.
Stefan ⛄ F. schrieb: > Nenne es ruhig "Scheiß Job". Gerne. Wenn man seinen Job in der Freizeit fortsetzt, aber sich offentlich so vor den Erzeugnissen der Kollegen ekelt, dass man keinerlei vorzeigbares Material zeigen könnte, trifft die Bezeichnung sicherlich zu. Da bin ich echt froh, dass gelungene Erzeugnisse aus meiner Zunft in jedem Haushalt und jedem Industriebetrieb zu finden sind.
Walter T. schrieb: > aber sich offentlich so vor den Erzeugnissen der Kollegen ekelt, > dass man keinerlei vorzeigbares Material zeigen könnte Wie meinst du das? Erwartest du dass ich die Erzeugnisse meiner Kollegen veröffentliche? Das darf ich nicht! Abgesehen davon ekele ich mich nicht vor den Erzeugnissen der Kollegen. Ganz im Gegenteil. Wer ekelt sich denn, du? Dann solltest du das mit deinen Kollegen klären. Harte Regeln funktionieren nicht, denn Softwareentwickler sind in gewissem Sinne auch Künstler. Aber man kann gute Kompromisse abstimmen, und gemeinsam richtig gute Produkte abliefern. Ich sage dir, warum ich Softwareentwickler bin: Weil ich es kann. Und weil das nur wenige Menschen können, wird der Job gut bezahlt. Ich versorge damit 4 Personen ohne finanzielle Sorgen. Ich kann nichts anderes, was ebenso gut bezahlt wird.
Stefan ⛄ F. schrieb: > Wie meinst du das? Erwartest du dass ich die Erzeugnisse meiner Kollegen > veröffentliche? So ein Unsinn. Als ob Deine Firma die einzige wäre, die Software herstellt. Aber offensichtlich beschäftigst Du Dich auf Quelltext-Ebene nur mit Sachen aus Deiner Firma (und wahrscheinlich Schnipsel aus TED-Talks). Das deutet auch nicht unbedingt auf einen Blick über den Tellerrand hin. Oder Deine Hauptarbeit ist tatsächlich das Diskutieren. Aber dann bist Du auch gar nicht der, den ich thematisch gefragt habe. Und ja: Ich betrachte auch Fachkollegen, die bei anderen Firmen arbeiten, als solche.
:
Bearbeitet durch User
Walter T. schrieb: > So ein Unsinn. Als ob Deine Firma die einzige wäre, die Software > herstellt. Du hast nach "Erzeugnissen der Kollegen" der Kollegen gefragt. Kollegen sind doch die Angestellten der selben Firma, oder nicht?
Programmierer schrieb: > ISBN 978-0201633610 > > Das Strategy-Pattern ist aber nicht sehr komplex, das gezeigte > Codebeispiel ist hier schon ziemlich ausreichend. Nach der ersten Sichtung: Das Buch geht komplett auf Design-Pattern in C++. Damit bringt es die Frage in dem verlinkten Thread kein bischen weiter, weil die Fragestellung in C++ gar nicht aufgetreten wäre.
jo schrieb: > https://link.springer.com/book/10.1007/978-3-540-76394-9 > > (( > https://www.tu-ilmenau.de/universitaet/fakultaeten/fakultaet-informatik-und-automatisierung/profil/institute-und-fachgebiete/institut-fuer-theoretische-informatik/fachgebiet-komplexitaetstheorie-und-effiziente-algorithmen/team/prof-m-dietzfelbinger/taschenbuch-der-algorithmen > )) Das Taschenbuch der Algorithmen ist genau das, was der Name verspricht. In meinen ersten Programmier-Monaten wäre es wunderbar gewesen, es zur Hand zu haben. Ich denke, es ist für ältere Schüler gedacht. Aber hier hilft es wohl nicht weiter. Gute Algorithmen zu finden, ist fast nie das Problem.
Walter T. schrieb: > Oder Deine Hauptarbeit ist tatsächlich das Diskutieren. Aber dann bist > Du auch gar nicht der, den ich thematisch gefragt habe. Diskutieren ist auf jeden Fall ein wesentlicher Bestandteil meiner täglichen Arbeit. So etwa 20% würde ich mal sagen. Ich wurde Senior Developer, weil ich mit meiner Erfahrung den Nachwuchs anleite und beaufsichtige. Also denke ich schon, dass auch du meine Meinung nicht geringschätzen solltest. Wenn du Schwierigkeiten damit hast, dann suche dir besser einen anderen Job. Denn nicht ich bin dann dein Problem, sondern deine Einstellung zur Arbeit.
> Ich werde für das Diskutieren bezahlt.
Die Maschinenbauer haben eine bessere Lösung gefunden als die
Softwareentwickler.
Dort werden nur ein paar Ingenieure beim Deutsches Institut für Normung
fürs Diskutieren bezahlt.
Der größte Teil der Ingenieure schaut in den DIN Normen nach, zu was für
einer Lösung die Diskussion geführt hat. Und alle anderen setzen einfach
das um, was die Ingenieure ausarbeiten.
In der Softwareentwicklung will jeder mit diskutieren. Ganz egal, ob er
versteht, wo das Problem liegt.
Der Opa aus der Muppet Show schrieb: > Der größte Teil der Ingenieure schaut in den DIN Normen nach > In der Softwareentwicklung will jeder mit diskutieren. Ja, da sagst du was wahres. Die Softwareentwicklung ist noch nicht so weit fortgeschritten.
Stefan ⛄ F. schrieb: > Wenn du Schwierigkeiten damit hast, dann suche dir besser einen anderen > Job. Denn nicht ich bin dann dein Problem, sondern deine Einstellung zur > Arbeit. Warum soll ich mir einen anderen Job suchen, wenn Du Dich mit Softwareentwicklung und Softwareentwicklern herumärgerst? Ich bin sehr froh darüber, das in meinem genau nicht zu tun. Der Opa aus der Muppet Show schrieb: > Dort werden nur ein paar Ingenieure beim Deutsches Institut für Normung > fürs Diskutieren bezahlt. Ich glaube, Du weißt nicht, wie Normen gemacht werden, oder ignorierst das. Der Opa aus der Muppet Show schrieb: > Die Maschinenbauer haben eine bessere Lösung gefunden als die > Softwareentwickler. Definitiv. Schon allein deswegen, weil Sachen, die fertig sein müssen, fertig sein müssen.
:
Bearbeitet durch User
Walter T. schrieb: >> Das API von free() (sofern es sich um eine standarkonforme >> Implementierung handelt) garantiert nämlich, dass im Falle eines >> Nullzeigers keine Aktion erfolgt. > > Auch das hätte ich völlig anders herum gesehen. Meine Denkweise wäre > gewesen: "Wenn die Implementierung standardkonform ist, wird die > doppelte Prüfung wegoptimiert, weil der Compiler in einer hosted > environment seine C-Lib-Funktionen ja kennt. Und wenn nicht, ist die > Prüfung jetzt da. Ist auch ein Argument. > Ich hatte dieses Pattern nie vorher in freier Wildbahn gesehen. strncpy(), snprintf() und Konsorten arbeiten so: du gibst eine Maximallänge an, die du zu speichern gewillt bist, die aufgerufene Funktion gibt allerdings unabhängig davon immer zurück, wieviel sie gespeichert _hätte_. Wenn die Maximallänge 0 ist, darf üblicherweise auch der Zeiger ein Nullzeiger sein, weil ja dann nie was zu speichern ist. Vorteil ist, dass es nicht unbedingt malloc() sein muss, wo der Aufrufer seinen Speicher her nimmt. Insbesondere kann man natürlich ein Schema haben: "Jeder vernünftig zu verarbeitende String hier passt in 100 Zeichen", den Puffer dafür stellt man fix bereit, und das "n" im Funktionsnamen agiert nur als "Notbremse" gegen Unfug. Das geht mit einem Pendant wie asprintf() nicht, die allozieren immer mit malloc(). Nachteil ist der zweimalige Aufruf (und der entsprechende zweimalige Rechenaufwand), wenn es komplett dynamisch und beliebig lang sein soll. Anderseits kann man durch den zweimaligen Aufruf bei "Ergebnis wird viel zu lang und kompletter Unsinn" nach dem ersten Lauf abbrechen, während eine Implementierung wie asprintf() stets versuchen wird, einen ggf. auch unsinnig großen Puffer zu allozieren.
Jörg W. schrieb: >> Auch das hätte ich völlig anders herum gesehen. Meine Denkweise wäre >> gewesen: "Wenn die Implementierung standardkonform ist, wird die >> doppelte Prüfung wegoptimiert, weil der Compiler in einer hosted >> environment seine C-Lib-Funktionen ja kennt. Und wenn nicht, ist die >> Prüfung jetzt da. > > Ist auch ein Argument. Machen sie allerdings leider nicht:
1 | #include <stdlib.h> |
2 | |
3 | void myfree(char *s) |
4 | {
|
5 | if (s != NULL) |
6 | free(s); |
7 | }
|
Mein Clang generiert daraus:
1 | .text |
2 | .file "foo.c" |
3 | .globl myfree # -- Begin function myfree |
4 | .p2align 4, 0x90 |
5 | .type myfree,@function |
6 | myfree: # @myfree |
7 | .cfi_startproc |
8 | # %bb.0: |
9 | pushq %rbp |
10 | .cfi_def_cfa_offset 16 |
11 | .cfi_offset %rbp, -16 |
12 | movq %rsp, %rbp |
13 | .cfi_def_cfa_register %rbp |
14 | testq %rdi, %rdi |
15 | je .LBB0_1 |
16 | # %bb.2: |
17 | popq %rbp |
18 | .cfi_def_cfa %rsp, 8 |
19 | jmp free # TAILCALL |
20 | .LBB0_1: |
21 | .cfi_def_cfa %rbp, 16 |
22 | popq %rbp |
23 | .cfi_def_cfa %rsp, 8 |
24 | retq |
25 | .Lfunc_end0: |
26 | .size myfree, .Lfunc_end0-myfree |
27 | .cfi_endproc |
28 | # -- End function |
29 | .ident "FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)" |
30 | .section ".note.GNU-stack","",@progbits |
31 | .addrsig |
Der Test ist also drin. :( Bei GCC 9 nicht anders.
Wie grob darf die Architektur sein? Wie fein sollte sie maximal werden? Ein groben Überblick gibt es hier: http://www.chibios.org/dokuwiki/doku.php?id=chibios:documentation:books:rt:architecture Allgemein gibt es eine Sicht auf das Ganze hier: http://www.chibios.org/dokuwiki/doku.php?id=chibios:documentation:books:rt:start
Jörg W. schrieb: > Machen sie allerdings leider nicht: Gut zu wissen. Also einer der Fälle, wo Faulheit beim Lesen der Doku mit drei verlorenen Takten betraft wird. Jörg W. schrieb: > strncpy(), snprintf() und Konsorten arbeiten so Stimmt, die kann man so nutzen. Ich habe es nur nie in Erwägung gezogen, weil auf dem µC die Textlängen ja durch die Darstellbarkeit auf dem Display von Natur aus begrenzt sind. Nico T. schrieb: > Wie grob darf die Architektur sein? Wie fein sollte sie maximal werden? Das Projekt gefällt mir immer besser. Wobei das Diagramm weitere Fragen aufwirft, nämlich ob die Macher es geschafft haben, dass so übersichtliche Diagramme direkt aus Doxygen herauspurzeln, oder ob das von Hand mit graphviz gemacht wurden.
:
Bearbeitet durch User
Thomas W. schrieb: > Walter T. schrieb: >> Hallo zusammen, >> >> schon seit langem stört mich, dass meine Fähigkeiten beim Programmieren >> in C stagnieren. Das ist nicht wirklich verwunderlich. Die meiste > > Ich bin ein wenig bloed: Natuerlich den Tanenbaum, Operating System, > design and implementation. Man kann ja zu Minix stehen wie man will, es > sind aber fortgeschrittene Lehrbuecher. Und, wie gewuenscht, reines C > mit Assembler fuer den Boot. > > Gruesse > > Th. Für alle Spezialisten, die jetzt wegen und über Minix lächeln: „… Im August 2017 wurde durch Untersuchungen von Sicherheitsforschern[5] bekannt, dass die Intel Management Engine Minix als Betriebssystem einsetzt.[6] Auch Tanenbaum hatte zuvor nichts davon gewusst. Durch den Einbau in die Intel-Chips ist Minix eines der meistverbreiteten Betriebssysteme überhaupt...“ ( Wiki )
Programmierer schrieb: > Das ist leider auch nur ein schöner Traum. In der Realität basteln die > Profis (also die, die dafür bezahlt werden) auch nur vor sich hin, Ja, leider. Letztens Quellcode von einem unserer "alten Hasen" in die Finger bekommen. Über so Dinge wie ungarische Notation bei den Bezeichnern oder die Plazierung von Klammern kann man ja streiten. Wenn allerdings alleine in der main() 25 gotos stehen (ja, goto. In C.), sieht man die Fähigkeiten dieser Kollegen in anderem Licht.
Nachdenklicher schrieb: > Wenn allerdings alleine in der main() 25 gotos stehen (ja, goto. In C.), Das sind halt die Kollegen, die vor 30 Jahren das Programmieren an der VHS in Basic lernten ;-)
Walter K. schrieb: > Das sind halt die Kollegen, die vor 30 Jahren das Programmieren an der > VHS in Basic lernten ;-) Weiß nicht, ob die auch Diplomstudiengänge anbieten? ;-) Der Kerl ist jedenfalls Diplominformatiker, und legt großen Wert darauf, von der Uni und nicht von der FH zu kommen.
Walter K. schrieb: > Thomas W. schrieb: > Für alle Spezialisten, die jetzt wegen und über Minix lächeln: Da war nicht als Kritik gemeint: Minix (ich hatte das Buch 1991 gekauft) benutzt einen MicroKernel (das war in den '90 sehr hip). Das ist (latuernich) heute nicht mehr so hip weil (prinzipbedingt) keine so grosse Performance hast (dafuer hat man eine starke Kapselung). Beim MicroKernel werden einzelne Funktionen des Kernels in getrennte Prozesse geteilt, die Kommunikation zwischen den Prozessen geht ueber Messagepassing. Und die Qualitaet einen Lehrbuches kann man schlecht messen (Zwei Meter Goethe, bitte!). Da Tanenbaum es aber im wesentlich allein gebaut hat und als Lehrsystem konzipiert hatte, ist es sehr konsistent. Und ein Unix auf einen 8086(!) hat auch Charme, vor allen Dingen wenn man von MS-DOS kommt. Viele Gruesse Th.
Nachdenklicher schrieb: > Walter K. schrieb: >> Das sind halt die Kollegen, die vor 30 Jahren das Programmieren an der >> VHS in Basic lernten ;-) > > Weiß nicht, ob die auch Diplomstudiengänge anbieten? ;-) Der Kerl ist > jedenfalls Diplominformatiker, und legt großen Wert darauf, von der Uni > und nicht von der FH zu kommen. Kann ja sein, dass jemand von der Uni kommt - aber dort hat man vielleicht Politik oder irgendwas mit Gerechtigkeit studiert … lol
Stefan ⛄ F. schrieb: > Aber ja, eine klare Trennung > zwischen Freizeit und Beruf gibt es in meinem Umfeld bei keinem guten > Softwareentwickler. Das machen nur die Looser, die nirgendwo länger als > 6 Monate bleiben. So ein Quatsch. So macht man sich kaputt und kann bald nie wieder arbeiten. Wer sich eine gesunde Trennung zwischen Privat & Arbeit schafft, privat dann einen Ausgleich (z.B. Sport) macht bleibt länger fit und produktiv, und das ist auch problemlos in unbefristeten langen Arbeitsverhältnissen machbar. Wer als Arbeitnehmer den Raubbau am eigenen Körper zum alleinigen Nutzen der Firma schon derart in sein eigenes Selbstverständnis aufgenommen hat, hat sich dem Kapitalismus völlig unterworfen... Walter T. schrieb: > - Viele Funktionen, die ungefähr etwas ähnliches machen, oder wenige > Funktionen mit ellenlangen Parameterlisten? Wenige Funktionen, ggf. templates, und cleveres Auftrennen von orthogonalen Elementen in eigene Funktionen sodass viele verschiedene Use Cases durch richtiges Kombinieren abgedeckt werden können. Klassisches Beispiel: Unix-Style fork+exec+dup2+pipe vs. Windows-Style CreateProcessEx zum Starten von Prozessen und abfangen des Stdout. Die Unix-Funktionen sind alle klein und leicht merkbar, während sich niemand all die Parameter und structs des Windows-Koloss merken kann! > - Ellenlange Funktionsaufrufe oder viele Zwischenvariablen? Geschmackssache. > - Der dicke Master Control Blob oder eine Ansammlung eng verknüpfter > voneinander abhängiger Funktionen? Einzelne wartbare Funktionen. > - Das große struct, in dem viele Funktionen herumschreiben, oder viele > lokale Variablen? Bloß nicht das "The Blob"-Antipattern! Viele kleine structs/Klassen. > - Fehlerbehandlung durch den Aufrufer oder den Aufgerufenen? Wie werden > Fehler signalisiert und wie behandelt? Exceptions ermöglichen ein konsistentes Weitergeben und Behandeln von Fehlern. Wo Fehler behandelt werden ist keine Frage des Stils sondern prinzipiell direkt durch die Anwendung vorgegeben. > - Parameterlisten fcn(In1, In2, *Out) oder fnc(*Out, In1, In2) > (__builtin_add_overflow() vs. memcpy() )? Ziemlich egal. > - Nur intern verwendete Structs voll sichtbar definieren und in den > Variablenraum der aufrufenden Funktion, oder verstecken und malloc() *)? OOP und public/private. > - Funktionen mit vielen Parametern oder mit Struct-Parametern? Egal. > - Konfiguration per Header oder per Build-Parameter? Am Besten per template-Parameter. > - Endmarker oder Längenvariable *)? Meistens Längenvariable. > - Behandlung von n+1-Fehlern: Prüfende Codeabschnitte (mit > Laufzeit-Overhead) oder Verantwortung auf den Aufrufer abwälzen? Solche und andere Programmierfehler kann man gut mit assert() prüfen. Man kann in vielen Fällen sowieso nicht vernünftig auf den Fehler reagieren (außer Programm abstürzen lassen). Nachdenklicher schrieb: > Wenn > allerdings alleine in der main() 25 gotos stehen (ja, goto. In C.), > sieht man die Fähigkeiten dieser Kollegen in anderem Licht. In C kann "goto" unter bestimmten Umständen sinnvoll sein, weil es keine vernünftige Ressourcenverwaltung (à la RAII) und Fehlerbehandlung beherrscht. Dann muss man es aber nach einem ganz bestimmten Schema einsetzen. Aber Deppen gibt's überall. Über die muss man sich nicht einzeln aufregen.
Walter K. schrieb: > Nachdenklicher schrieb: >> Wenn allerdings alleine in der main() 25 gotos stehen (ja, goto. In C.), > > Das sind halt die Kollegen, die vor 30 Jahren das Programmieren an der > VHS in Basic lernten ;-) Eher die, die von FORTRAN auf C umgestiegen sind. Dazu passend würden dann noch sackweise globaler Variablen mit 6 Zeichen langen Namen gehören. ;-)
Programmierer schrieb: > So ein Quatsch. So macht man sich kaputt und kann bald nie wieder > arbeiten. Es ist eine Frage der richtigen Balance. Man solle es nicht übertreiben. > Wer sich eine gesunde Trennung zwischen Privat & Arbeit > schafft ... bleibt länger fit und produktiv, und das ist auch > problemlos in unbefristeten langen Arbeitsverhältnissen machbar. Natürlich, eine gesunde Trennung kann ich nur jedem Empfehlen. Gesunde Trennung heißt nicht vollständige Trennung. Manchmal (vielleicht 3x im Jahr) werde ich Abends oder am Wochenende vom Betrieb um Hilfe gebeten. Das mache ich gerne. Einmal in 30 Jahren habe ich meinen Urlaub vorzeitig abgebrochen und wurde dafür fair entschädigt. Ich setze viel Freizeit zum Lernen ein. Niemand zwingt mich dazu. Neulich wurde in der Firma beschlossen, dass wir Teile eines Cloud Systems in Go programmieren werden (Go kannte ich bis dahin noch nicht). Danach habe ich drei Wochenenden mit Tutorials verbracht, um die Grundlagen der Sprache zu lernen und alle für uns relevanten Schnittstellen durchzuchecken. Das halte ich für normal. Ich kann nicht von der Schule/Uni kommen und glauben, dass ich in den nächsten 40 Jahren nichts mehr dazu lernen muss. Manchmal wird man während der Arbeitszeit zu teuren Schulungen geschickt, aber das eben nur manchmal. Für diesen Luxus fehlt es meistens an Zeit und Geld. Zumal man nach den Schulungen auch viel Zeit braucht, das komprimierte Wissen zu verinnerlichen und auszuprobieren. Im Gegenzug kann ich jederzeit mal eine Pause zum Einkaufen machen oder kurzfristig (quasi sofort) bis zu einem Tag frei nehmen. Mich fragt auch niemand, wie lange ich auf dem Klo sitze (Kreativpausen) oder ob ich mein Mittagessen schnell genug herunter gewürgt habe. Es ist ein gegenseitiges Geben und Nehmen. Auf jeden Fall ist wichtig, dass man seinen Mund aufmacht und mit dem Chef über Bedürfnisse beider Seiten (!) sprechen kann.
Jörg W. schrieb: > Walter K. schrieb: >> Nachdenklicher schrieb: >>> Wenn allerdings alleine in der main() 25 gotos stehen (ja, goto. In C.), >> > > Eher die, die von FORTRAN auf C umgestiegen sind. > > Dazu passend würden dann noch sackweise globaler Variablen mit 6 Zeichen > langen Namen gehören. ;-) Mein Highlight ist computed GOTO in Fortran77 (aus: https://riptutorial.com/fortran/example/11873/computed-goto)
1 | Computed GOTO allows branching of the program according to the value of an integer expression. |
2 | |
3 | GOTO (label_1, label_2,... label_n) scalar-integer-expression |
4 | |
5 | If scalar-integer-expression is equal to 1 the program continues at statement label label_1, if it is equal to 2 it goes to label_2 and so on. If it is less then 1 or larger than n program continues on next line. |
Goto to Hell! Gruesse Th.
Thomas W. schrieb: > Mein Highlight ist computed GOTO in Fortran77 > Goto to Hell! Allerdings. In Basic gab es mal eine Zeit ohne Prozeduren, labels und Schleifen (außer FOR). Da hatte jedes Programm hunderte Gotos die kreuz und quer zu bestimmten Zeilennummern sprangen. We man Code einfügte, stimmten die ganzen Zeilennummern nicht mehr. Das ist die Zeit, in der ich das Programmieren lernte. Früher war nicht alles besser, definitiv nicht.
Stefan ⛄ F. schrieb: > Es ist eine Frage der richtigen Balance. Man solle es nicht übertreiben. Die 40h-Woche ist schon an der Grenze. Stefan ⛄ F. schrieb: > Ich setze viel Freizeit zum Lernen ein. Niemand zwingt mich dazu. Ich dachte wer das nicht macht ist ein Loser? Stefan ⛄ F. schrieb: > Danach habe ich drei Wochenenden mit Tutorials verbracht, um die > Grundlagen der Sprache zu lernen und alle für uns relevanten > Schnittstellen durchzuchecken. Also 4 Wochen durchgearbeitet ohne Pause? 3 Wochenenden, d.h. 6 Tage Lebenszeit der Firma geschenkt, nur weil in der Woche "keine Zeit" dafür ist? Das findest du gesund? Irre. Wenn ich was für die Firma lernen soll, dann muss die Firma mir dafür Platz in der bezahlten Arbeitszeit machen. Wenn das nicht geht, müssen sie eben noch wen einstellen. Schlimm genug dass Manager eine solche Aufopferung irgendwie voraussetzen, noch schlimmer wenn Arbeitnehmer das für sich selbst und Gruppenzwang-mäßig für ihre Kollegen als selbstverständlich sehen (weil alle anderen Loser sind?). Scheint auch im akademischen Umfeld sehr beliebt zu sein. Thomas W. schrieb: > Mein Highlight ist computed GOTO in Fortran7 Sowas ähnliches kann der GCC auch: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
Programmierer schrieb: > Scheint auch im akademischen Umfeld sehr beliebt zu sein. So ist es. Entweder lässt du dich drauf ein und spielst mit, oder eben nicht. Wer nicht mit macht, jobbt sich mühsam von Firma zu Firma durch weil er nirgendwo lange bleiben kann. Zudem kommt man so nicht auf ein ordentliches Gehalt. So ist der Alltag der allermeisten Softwareentwickler. Warum sollte ich hier eine heile Welt propagieren, die nicht existiert? Lieber den Beruf so akzeptieren wie er ist, oder halt einen anderen Beruf wählen.
Stefan ⛄ F. schrieb: > Entweder lässt du dich drauf ein und spielst mit, oder eben > nicht. Wer nicht mit macht, jobbt sich mühsam von Firma zu Firma durch > weil er nirgendwo lange bleiben kann. Zudem kommt man so nicht auf ein > ordentliches Gehalt. Das stimmt halt absolut nicht. Ich mache genau 40h pro Woche, hatte bisher immer unbefristete Verträge, musste nie "jobben" und verdiene sehr gut. Niemand wird rausgeworfen weil er vernünftige Arbeitszeiten einhält. Außerdem nimmt die Arbeitsleistung auch irgendwann wieder ab, d.h. mehr Arbeiten ist weniger Leistung. Stefan ⛄ F. schrieb: > So ist der Alltag der allermeisten Softwareentwickler Quatsch. Ganze Heerscharen von "white-collar"-Programmierern machen geregelte Arbeitszeiten. Das ist das Tolle an der Software-Branche - man kann relativ unkompliziert einen stabilen Job mit geregelter Arbeitszeit bekommen. Vielleicht bist du einfach nur ein einer toxischen Ausbeutungs-Betrieb?
Stefan ⛄ F. schrieb: > Da hatte jedes Programm hunderte Gotos die kreuz und quer zu bestimmten > Zeilennummern sprangen. We man Code einfügte, stimmten die ganzen > Zeilennummern nicht mehr. Die Zeilennummern wurden in 10-er Schritten hochgezählt, damit man noch Zeilen einfügen kann. Beim neu Numerieren wurden natürlich auch die Gotos und Gosubs angepaßt. Ansonsten wäre ja das Programm für die Mülltonne.
Thomas W. schrieb: > Mein Highlight ist computed GOTO in Fortran77 Meins auch. ;-) > Goto to Hell! Du meinst:
1 | GOTO (10, 20, 30) i |
2 | |
3 | 10 GOTO 30 |
4 | 20 CONTINUE |
5 | 30 CALL HELL |
Stefan ⛄ F. schrieb: > Thomas W. schrieb: >> Mein Highlight ist computed GOTO in Fortran77 >> Goto to Hell! > > Allerdings. > > In Basic gab es mal eine Zeit ohne Prozeduren, labels und Schleifen > (außer FOR). > > Da hatte jedes Programm hunderte Gotos die kreuz und quer zu bestimmten > Zeilennummern sprangen. We man Code einfügte, stimmten die ganzen > Zeilennummern nicht mehr. Es gab schon Gosub/return und man konnte Zeilennummer-Bloecke benutzen (das war meine Methode um Libraries zu bauen. Lang ist es her). Gruesse Th.
Programmierer schrieb: > Thomas W. schrieb: >> Mein Highlight ist computed GOTO in Fortran7 > > Sowas ähnliches kann der GCC auch: > https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html Kannte ich noch nicht. Ich habe es erfolgreich vergessen. Gruesse Th.
Stefan ⛄ F. schrieb: > Thomas W. schrieb: >> Mein Highlight ist computed GOTO in Fortran77 >> Goto to Hell! > > Allerdings. > > In Basic gab es mal eine Zeit ohne Prozeduren, labels und Schleifen > (außer FOR). Wenn die Sprache nichts anderes her gibt, ist dsa ja auch alles okay. Beschwert sich ja auch keiner über Jumps in Assembler. Aber wenn die Sprache besseres kann...
Das ist also ein Konstrukt, das Anfänger unbedingt vermeiden sollten und nur von Profis verwendet werden soll, die wissen, was sie tun? Dann muss ich ja schon aus Prinzip in meinem aktuellen Projekt eine Möglichkeit finden, das irgendwo einzusetzen. Wahrscheinlich lassen sich Wartezeiten so gut erzeugen.
:
Bearbeitet durch User
Walter T. schrieb: > Das ist also ein Konstrukt, das Anfänger unbedingt vermeiden sollten und > nur von Profis verwendet werden soll, die wissen, was sie tun? Anfänger sollten es grundsätzlich nicht benutzen, und Profis wissen auch warum, und nutzen es daher auch nicht! Eine Ausnahme wäre die Sache mit der Ressourcenverwaltung:
1 | int fun (void) { |
2 | SomeResource1 res1 = allocateResource1 (); |
3 | int ret = 0; |
4 | if (!res1) { ret = 1; goto End; } |
5 | |
6 | SomeResource2 res2 = allocateResource2 (); |
7 | if (!res2) { ret = 1; goto FreeRes1; } |
8 | |
9 | SomeResource3 res3 = allocateResource3 (); |
10 | if (!res3) { ret = 1; goto FreeRes2; } |
11 | |
12 | doSomething (res1, res2, res3); |
13 | |
14 | freeResource3 (res3); |
15 | |
16 | FreeRes2:
|
17 | freeResource2 (res2); |
18 | |
19 | FreeRes1:
|
20 | freeResource1 (res1); |
21 | |
22 | End:
|
23 | return ret; |
24 | }
|
Wenn man sich strikt an das Schema hält ist es einigermaßen akzeptabel, da relativ übersichtlich. Allerdings ist es leicht sich zu vertun und zum falschen Label zu springen. In C++ mit RAII, Exceptions (und ggf. Smart-Pointern) ist es um Welten einfacher:
1 | void fun (void) { |
2 | SomeResource1 res1; |
3 | SomeResource1 res2; |
4 | SomeResource1 res3; |
5 | |
6 | doSomething (res1, res2, res3); |
7 | }
|
Korrekt implementierte Ressourcen-Klassen vorausgesetzt. Im Fehlerfall wird eine Exception geworfen, die bereits allokierten Ressourcen freigegeben und der Fehler an den Aufrufer gemeldet. Da man auf Mikrocontrollern aber weniger dynamisch allokierte Ressourcen hat (Speicher, Dateien, Betriebssystem-Handles) ist dieses Problem hier weniger relevant. Walter T. schrieb: > Wahrscheinlich lassen sich Wartezeiten > so gut erzeugen. Die muss man wenn schon mit (Inline-)Assembler erzeugen. Gerade bei den Cortex-M ist das aber schwer kalkulierbar, da ist ein Timer definitiv die bessere wahl. Thomas W. schrieb: > Kannte ich noch nicht. Ich habe es erfolgreich vergessen. Ist auch besser so. Ich habe das noch nie gebraucht.
Programmierer schrieb: > Gerade bei den > Cortex-M ist das aber schwer kalkulierbar, da ist ein Timer definitiv > die bessere wahl. Wie langweilig. Da nehme ich doch lieber computed goto und eine lange Nop-Rutsche. Huuuiiiiiii! Aber im Ernst: Ich versuche mir wirklich gerade seit knapp einer Stunde vorzustellen, wofür man den Kram eingebaut hat.
:
Bearbeitet durch User
Also meine Empfehlung (als Auch-Hobbyist) wäre ein größeres Desktopprogramm in einer anderen Sprache (und zwar objektorientiert) umzusetzen. Man kommt so etwas von den Mikrooptimierungen weg, wie man sie auf Mikrocontrollern und besonders mit C gewohnt ist (Der TE hat ja gezeigt, dass er da etwas feststeckt). Hat man sich selber Konzepte ersonnen, weil sie im Kontext eines größeren Programmes einfach wichtig und hilfreich, teilweise notwendig, sind, dann erkennt man das nächste Mal das Konzept auch in Fremdcode wieder. Das gleiche gilt für Sprachmerkmale. Wenn man bspw. an einer Stelle steht, wo man sich denkt, man bräuchte jetzt eine bestimmte Funktionalität, sucht danach und findet tatsächlich ein Sprachmerkmal als Lösung. Dann hat man es in dem Moment durchdrungen. Bei der Mikrocontrollerprogrammierung muss man dann oft wieder die Abstrahierung reduzieren, aber dadurch, dass man dann beides gut kennt, kann man besser abschätzen, an welchen Stellen eine höhere Abstraktion sinnvoll ist und an welchen man eine Funktionalität auch mal einfach an Ort und Stelle in ein paar Codezeilen abvespert, ohne ein Framework drumherum zu bauen. Beim Programmieren ist das doch gerade das Problem, dass es nicht die universellen Allgemeinrezepte gibt, die in jedem Kontext funktionieren und jedes Programm zu einem Fünfzeiler vereinfachen. Sondern dass in jeder Zeile Code ein Kompromiss steckt zwischen Funktionalität, Lesbarkeit, Ver- und Entflechtung, Abstraktion, Codedoppelungen, Wiederverwendbarkeit usw. Das macht aber m.E. auch gerade die Würze beim Programmieren aus. Das ist der Unterschied zwischen einer Strafarbeit, wo man hundert mal das gleiche runterschreiben muss "Ich soll keine Mikrooptimierungen betreiben. Ich soll keine Mikrooptimierungen betr...", und einem freien Aufsatz "Warum ich keine Mikrooptimierungen betreiben soll". Oder anders gesagt, wenn man einen fremden Code eines gewissen Niveaus liest, und die Qualität nicht beurteilen kann, ist man noch nicht weit genug und muss in eigenen Programmen üben. Das schließt Literatur und Codestudium ja nicht aus, nur beides muss man selber einordnen und bewerten.
Maxe schrieb: > Also meine Empfehlung (als Auch-Hobbyist) wäre ein größeres > Desktopprogramm in einer anderen Sprache (und zwar objektorientiert) > umzusetzen. Man kommt so etwas von den Mikrooptimierungen weg, wie man > sie auf Mikrocontrollern und besonders mit C gewohnt ist (Der TE hat ja > gezeigt, dass er da etwas feststeckt). Ich fürchte, die Tatsache, in der Vergangenheit große Finite-Elemente-Programme (objektorientiert) in Matlab geschrieben zu haben, ist eher ein großes Hindernis. Für eine Stapelverarbeitung gelten ganz andere Regeln als für zyklische Programme. Bei ersteren ist eher die Speicherbandbreite das Problem, bei den letzteren die kombinatorische Komplexität. Sowieso ist meistens die Kernfunktionalität recht geradeheraus programmierbar, aber die GRAfische BenutzerSCHnittstelle (GraBSch) macht den meisten Aufwand und hat die meisten Fehler. Gerade auf dem µC, wo man alles selbst machen muss.
:
Bearbeitet durch User
Walter T. schrieb: > Maxe schrieb: > Sowieso ist meistens die Kernfunktionalität recht geradeheraus > programmierbar, aber die GRAfische BenutzerSCHnittstelle (GraBSch) macht > den meisten Aufwand und hat die meisten Fehler. Gerade auf dem µC, wo > man alles selbst machen muss. Der Aufwand eine gute graphische Benutzerschnittstelle (UI) zu programmieren geht vermutlich exponentiell mit der Zahl der Elemente (Widget). Und dann bitte scalieren und fuer einen kleinen grossen Telefon-Schirm programmieren. Datenerfassungsmasken (gut gemacht) planen und programmieren ist sehr aufwaendig. Und der Benutzer sieht auch alle Fehler sofort (und die Sache soll ja idiotensicher sein). Gruesse Th.
Moin, traurig schrieb: > Robert Martin mit seinem "Clean Code" scheint ein richtiger Profi > zu > sein. > > Wo findet man denn seine Programme und seinen Quellcode? Oder hat er > auch nur geheimen Programmcode für seine Arbeitgeber geschrieben? ;-) Ja, zumindest kann ich dem auf Youtube ein paar Vortraege lang zuhoeren und -glotzen. Und bin dann nicht so angenervt wie nach ein paar Minuten Youtubevideo mit Ubuntubildschirm, Mausgeschubse und heftigem Akzent des Schubsers und Vortragenden in Personalunion. Auch wenn ich noch keinen Code von ihm gesehen hab'; zumindest didaktisch kann er's mir gut rueberbringen. Gruss WK
Walter T. schrieb: > Wenn ich eine Fremdsprache lerne und über das Volkshochschulniveau > hinaus bin, nutze ich > a) Literatur über die Sprache > b) Literatur in der Sprache auf bekannter Niveauebene. > c) Versuche in der Sprache zu hören > d) und in der Sprache zu sprechen. es gibt noch e) bspw. wie Adam Dunkels die Sprache C mit selbstgeschrieben Makros (pt_Yield etc.) erweitern und damit kreativer eigene Programme schreiben zu können
Walter T. schrieb: > Es wird wohl auf das Lesen von Quelltext hinauslaufen. Das Problem: Wie > findet man guten Quelltext zum Lesen? In Foren o.Ä. findet man ja > hauptsächlich Schnipsel und zweifelhafte Fälle. Zu lesen gibt es viel, ob dir das was bringt ist eine andere Sache.. IME ist direktes Feedback am besten, zB. wenn du eine Änderung durch eine Code Review schickst, da gibt es dann feedback. Ist natürlich nicht so einfach möglich wenn dein Repo bzw. Code nicht öffentlich ist oder keienr da ist für den Review. Da gibt es zB. auch Code Reviews auf Stackoverflow: https://codereview.stackexchange.com/ Da kannst du deinen Code reinstellen und bekommst dann zu hören was andere davon halten :) Clean Code von Robert Martin finde ich sehr gut, mag seine politischen Ansichten nicht (muss ich ja nicht), bei live Vorträgen finde ich ihn etwas ermüdend. Lesen kann ma so viel man will, programmieren ist ein Handwerk, da muss geübt werden und jemand sollte einem auf die Finger gucken :)
Mladen G. schrieb: > programmieren ist ein Handwerk, da muss > geübt werden und jemand sollte einem auf die Finger gucken :) es gibt das Handwerk in Großraumbüros ähnlich im Zeitungsbereich bei dem Autoren auf die Finger geguckt wird und es gibt Künstler wie Adam Dunkel die programmieren/schreiben alleine, ohne dass ihnen dabei jemand auf die Finger guckt. Ich hab gerade eine Inspiration von Adam Dunkels protothreads fertiggestellt zu der es u.a. die Meinungen - Arduino-Autor EAF meinte zur Setup-Funktion:"hässlichste Stück Arduino Code, was mit seit langem unter gekommen ist" - ich persönlich sehe in Procedure w_pin_ und ISR simul_100hz_upd noch sehr sehr deutlichen Verbesserungsbedarf. gibt. https://wokwi.com/arduino/projects/308011153834902082 Vom Prinzip eignen sich unterschiedliche Quelltexte bei gleicher technischer Leistung hervorragend, um sich eine Meinung bilden zu können.
Alter Schwede, ja das kann man nur als Kunst bezeichnen! Wäre toll, wenn jeder Programmierer für seine Software seine eigene kunstvolle Sprache mittels Makros bastelt, sodass garantiert alle alleine arbeiten müssen, weil niemand anders den Code versteht! Hat auch den Vorteil, dass kein Software-Projekt komplexer werden kann als die Arbeitsleistung eines einzelnen Programmierers ermöglicht. Ganz davon abgesehen dass der Künstler offenbar C++ auch nicht so richtig beherrscht, #define statt typedef/using und statt Konstanten? Aber immerhin eine Anwendung für Labels as Values! Spricht das jetzt dafür oder dagegen?
Stefan schrieb: > - Arduino-Autor EAF meinte zur Setup-Funktion:"hässlichste Stück Arduino > Code, was mit seit langem unter gekommen ist" Ja, das ist meine Meinung! OK, die ist arg subjektiv...... Das mit dem Dunkels seine Threads kann man auch hübscher hinbekommen. Wobei das, wenn der Präprozessor einmal damit durch ist, in der Zwischendatei, sowieso nie schön aussieht. Egal, ob man es sich mit computed Goto oder verquerem switch/case bastelt. Also konkreter: Man kann den hässlichen Teil in einer Lib verstecken.
Walter T. schrieb: > (objektorientiert) [...] Stapelverarbeitung Passt das denn zusammen?? > Matlab Als ich das letzte Mal Matlab benutzt habe war das keine "Programmiersprache". > Sowieso ist meistens die Kernfunktionalität recht geradeheraus > programmierbar, aber die GRAfische BenutzerSCHnittstelle (GraBSch) macht > den meisten Aufwand und hat die meisten Fehler. Gerade auf dem µC, wo > man alles selbst machen muss. Die OOP kommt nicht umsonst aus dem Bereich der Grafikprogrammierung. Zur Zeit bin ich an einer sensorlosen BLDC-Ansteuerung. Da stellt sich die Frage, ob man die Drehzahlregelung mit in der Kommutierung verwurstelt oder eine eigene Unit/Klasse vorsieht. Ich hab mich für die getrennte Implementierung entschieden. Dann könnte man die Geschwindigkeitsregelung über den Timerinterrupt in voller Geschwindigkeit mitlaufen lassen, obwohl man nur bei jedem Kommutieren einen aktuellen Geschwindigkeitswert hat. Oder die Units wieder verflechten mit gegenseitigen Funktionsaufrufen, vielleicht zumindest durch Callbacks getrennt...
Programmierer schrieb: > Aber immerhin eine Anwendung für > Labels as Values! Spricht das jetzt dafür oder dagegen? Da gibts nur die beiden Möglichkeiten computed Goto oder verquerem switch/case. Und Goto ist da schon ok. OK, longjump wenn man sich nach der Decke streckt, aber damit wirds auch nicht hübscher.
Programmierer schrieb: > Das stimmt halt absolut nicht. Ich mache genau 40h pro Woche, hatte > bisher immer unbefristete Verträge, musste nie "jobben" und verdiene > sehr gut. Da werde ich ja glatt neidisch. In welcher Branche ist das?
Stefan ⛄ F. schrieb: > Da werde ich ja glatt neidisch. In welcher Branche ist das? Industrie, Sondermaschinenbau. Zuvor was ganz anderes in einem Internet-Medien-Unternehmen, ähnlich gute Konditionen. In beiden Fällen direkt nach dem VG eingestellt, kein Assessment-Center o.ä. was auf großen Andrang/Konkurrenz hindeuten würde.
Peter D. schrieb: > Beim neu Numerieren wurden natürlich auch die > Gotos und Gosubs angepaßt. Rate mal, wer das damals immer wieder Stefan schrieb: > Ich hab gerade eine Inspiration von Adam Dunkels protothreads > fertiggestellt ... Falls jemand nicht weiß, was das ist, habe ich hier eine kleine deutsche Einführung: http://stefanfrings.de/net_io/protosockets.html Protothreads habe ich genau einmal in einem einzigen Projekt verwendet, und zwar in Kombination mit Protosockets. Am Anfange dachte ich noch "WTF ist das denn?". Nach einer Weile gewöhnte ich mich daran und es kam mir nicht mehr komplizierter vor als Zustandsautomaten mit switch/case. Aber inzwischen habe ich es schon wieder vergessen. Bei switch/case ist für mich der Programmfluss und der Gültigkeitsbereich von Variablen offensichtlicher, als mit seinen Makros. Außerdem haben mich die unverständlichen Fehlermeldungen des Compilers immer kirre gemacht, wenn man die Makros nicht in der korrekten Reihenfolge hin schrieb oder Tippfehler machte. Nach wie vor finde ich die Protothreads sehr interessant und lehrreich, benutzen möchte ich sie aber nicht mehr.
Stefan ⛄ F. schrieb: > benutzen möchte ich sie aber nicht mehr. Dutzendfach im täglichen Betrieb.... Tuts perfekt. Beispiel, ein weiteres BlinkWithoutDelay:
1 | #pragma once
|
2 | |
3 | #include <CooperativeTask.h> |
4 | |
5 | |
6 | class BlinkTask: public Task |
7 | {
|
8 | protected:
|
9 | const byte pin; |
10 | const unsigned long interval; |
11 | |
12 | public:
|
13 | BlinkTask(const byte pin,const unsigned long interval): |
14 | pin(pin), |
15 | interval(interval) |
16 | {
|
17 | }
|
18 | |
19 | virtual void init() |
20 | {
|
21 | Serial.print("BlinkTask begin, pin: "); Serial.println(pin); |
22 | pinMode(pin,OUTPUT); |
23 | }
|
24 | |
25 | virtual void run() |
26 | {
|
27 | TaskBlock
|
28 | {
|
29 | digitalWrite(pin,HIGH); |
30 | taskPause(interval); |
31 | digitalWrite(pin,LOW); |
32 | taskPause(interval); |
33 | }
|
34 | }
|
35 | |
36 | |
37 | virtual ~BlinkTask() |
38 | {
|
39 | digitalWrite(pin,LOW); |
40 | pinMode(pin,INPUT); |
41 | }
|
42 | |
43 | };
|
EAF schrieb: > Dutzendfach im täglichen Betrieb.... Tuts perfekt. > Beispiel, ein weiteres BlinkWithoutDelay: Der Herr Dunkels hat es halt als sportliche Herausforderung gesehen, eine Art Multitasking mit minimalem technischen Overhead zu implementieren. Sein µIP Projekt ist auch von dieser Art. Ich vermute dass sich heute fast keiner mehr den Aufwand in dieser Form antut, aber damals war das schon cool.
Walter T. schrieb: > Anscheinend lesen Softwareentwickler nicht gern Quelltext. Nur die Faulen und Dummen. > Das > unterscheidet sie von den Ingenieuren. Nun, die erfahrenen (also implizit nichtfaulen und nichtdummen) Softwareentwickler sind Ingenieure. Auch wenn sie vielleicht nicht unbedingt immer den akademischen Titel nachweisen können... > oder sie finden grundsätzlich die Arbeit anderer häßlich. Das ist tatsächlich ein ernsthaftes Problem. Denkmuster unterscheiden sich und Betrachtungswinkel unterscheiden sich. Typisches Beispiel: Wer OO-Code gewohnt ist, wird jeden C-Code zu irgendeinem nichttrivialen Problem als dramatisch suboptimal empfinden. Lustigerweise inbesondere dann, wenn der C-Programmierer "C mit Klassen" umgesetzt hat... Aber generell gilt vorallem: Der meiste Code wird typisch mit dem Fokus auf eine konkrete Anwendung umgesetzt. Das ist das, was ich "Betrachtungswinkel" nenne. Mit einem anderen Betrachtungswinkel scheint er oft dramatisch schlecht zu sein, und oft ist er auch objektiv zumindest ein wenig schlecht. Weil er nicht hinreichend universell ist. Das wird aber dann den nunmehr neu erstellten Code mit einiger Wahrscheinlichkeit wiederum genauso betreffen, wenn er dann mal von irgendjemand anderem reviewed wird (unter dessen Betrachtungswinkel) ;o) > Was mir am ChibiOS-Beispiel gefällt: Die Dokumentierung der > Einzelfunktionen mit Doxygen ist in den Teilen, die ich mir bis jetzt > angeguckt habe, absolut mustergültig. Das sind gleich drei Fehler, die keinem erfahrenen Programmierer jemals passieren würden: 1) Anzunehmen, dass sie irgendwas über Konzepte des Codes verrät... 2) Anzunehmen, das sie ernsthaft mehr verrät als die Signaturen der beschriebenen Methoden/Funktionen... 3) (folgt aus 1) und 2)): nicht kapiert, dass das meist nur automatisch generierter Bullshit ist, mit exakt dem Informationsgehalt, der auch im Prototypen steht.. Du hast da ganz offensichtlich allein die blosse Existenz positiv bewertet...
Maxe schrieb: > Walter T. schrieb: >> (objektorientiert) [...] Stapelverarbeitung > > Passt das denn zusammen?? > >> Matlab > > Als ich das letzte Mal Matlab benutzt habe war das keine > "Programmiersprache". Das passt hervorragend zusammen. Stapelverarbeitung ist ja auch eher datenzentrisch. Auch heute ist es nur eine Programmiersprache ohne Anführungszeichen. Aus irgendeinem Grund wird es aber mehr prozedural als objektorientiert genutzt, obwohl das hervorragend geht. Mladen G. schrieb: > IME ist direktes Feedback am besten, zB. wenn du eine Änderung durch > eine Code Review schickst, da gibt es dann feedback. > Ist natürlich nicht so einfach möglich wenn dein Repo bzw. Code nicht > öffentlich ist oder keienr da ist für den Review. Das ist der Punkt. Das ist sowieo bei vielen Embedded-Projekten der Punkt: Der Kreis der Leute, die es nutzen können wollten und der, der es weiterentwickeln könnte, hat oft wenige Überschneidungen. Mit "Open Source" bekommt man dann viele Anfragen und Verbesserungs"wünsche" und böse Worte, ohne jemals selbst etwas davon zu haben. c-hater schrieb: > 3) (folgt aus 1) und 2)): nicht kapiert, dass das meist nur automatisch > generierter Bullshit ist, mit exakt dem Informationsgehalt, der auch im > Prototypen steht.. Kann ich nicht bestätigen. Die erste Quelltext-Datei, die ich mir angeguckt habe, ist die hier: https://osdn.net/projects/chibios/scm/svn/blobs/head/trunk/os/oslib/src/chmemcore.c Nachd dem lästigen Disclaimer steht ziemlich klar, was die Funktionen dieser Datei machen und wozu sie da sind. Über den Funktionen selbst ist nochmal die Signatur in Schönschrift, damit die IDE das beim Auto-Vervollständigen schon anzeigen kann, aber unnötig lang ist das auch nicht.
:
Bearbeitet durch User
c-hater schrieb: > Nun, die erfahrenen (also implizit nichtfaulen und nichtdummen) > Softwareentwickler sind Ingenieure. Und was ist hier die Definition von "Ingenieur"? Softwareentwicklung und Ingenieursarbeit sind gar nicht so ähnlich. Dass erfahrene Softwareentwickler automatisch zu Ingenieuren werden macht also wenig Sinn.
Walter T. schrieb: > [...] aber unnötig lang ist das auch nicht. Oder ist das genau die Länge, die stört? Ja, Doxygen braucht immer ein wenig Boilerplate-Kommentar, wenn man das so nennen darf. Das ist gewöhnungsbedürftig.
Mit Doxygen kann man per Knopfdruck viel "Papier" erzeugen. Manche Manager fahren darauf total ab. Der Nutzen ist in der Praxis eher gering. In der Firma wo ich derzeit arbeite dokumentieren wir nur das, was nicht offensichtlich ist. Sowas wie:
1 | /** |
2 | * Log a user in and return an access token. |
3 | * @param username Name of the calling user |
4 | * @param password of the calling user |
5 | * @return The access token |
6 | * @throws AuthenticationFailureException error |
7 | */ |
8 | AcessToken userLogin(String username, String password) throws AuthenticationFailureException; |
geht gar nicht. Wir haben wichtigeres zu tun, als wertloses "Papier" zu erzeugen. Viel hilfreicher wäre so etwas, falls es zutrifft:
1 | * @return The access token or null if the login failed. |
2 | * @throws AuthenticationFailureException only in case of a configuration error |
Ob das mit dem Null Wert eine gute Idee ist, darüber kann man streiten. Aber es zu dokumentieren ist auf jeden Fall hilfreich. Ebenso wüsste ich bei Listen/Arrays auch immer gerne, ob sie im Fall von "nichts gefunden" leer oder null sind.
Programmierer schrieb: > Und was ist hier die Definition von "Ingenieur"? Softwareentwicklung und > Ingenieursarbeit sind gar nicht so ähnlich. Doch, natürlich. Extrem ähnlich. Mit "Softwareentwicklung" ist hier natürlich nicht das Tagewerk von gehirnamputierten Codiersklaven gemeint. > Dass erfahrene > Softwareentwickler automatisch zu Ingenieuren werden macht also wenig > Sinn. Doch, das macht mindestens denselben Sinn, mit dem Handwerksmeister die Fähigkeiten von frisch graduierten Ingenieuren passender Fachrichtung erlangen (und weit, weit überschreiten können).
c-hater schrieb: > Mit "Softwareentwicklung" ist hier natürlich nicht das > Tagewerk von gehirnamputierten Codiersklaven gemeint. Gibt es diesen Job überhaupt in Echt? Also jemand, der strunz doof 1:1 von UML oder Prosa in eine Programmiersprache übersetzt? Muss nicht jeder Programmierer zumindest Teil-Konzepte selbst erstellen und sich die Strukturen sowie Fehlerbehandlungs-Routinen ausdenken?
Stefan ⛄ F. schrieb: > In der Firma wo ich derzeit arbeite dokumentieren wir nur das, was nicht > offensichtlich ist. Sowas wie: > /** Log a user in and return an access token. > * > * @param[in] username Name of the calling user > * @param[in] password of the calling user > * @return The access token or NULL if login failed > * @throws AuthenticationFailureException error > */ > AcessToken userLogin(String username, String password) throws > AuthenticationFailureException; > > geht gar nicht. Es ist dann überflüssig, wenn es nachträglich geschrieben wurde. Wenn es vorher geschrieben wurde, sieht es anders aus (ich habe mir mal die Freiheit herausgenommen, den Kommentar zu vervollständigen). Dann schreibt man erst, was die Funktion machen soll und benutzt das dann als Spezifikation. Oft ist das Runterschreiben der Funktion selbst dann total einfach. Wenn das andersherum gemacht wird, ist das ziemlich überflüssig.
c-hater schrieb: > Programmierer schrieb: > >> Und was ist hier die Definition von "Ingenieur"? Softwareentwicklung und >> Ingenieursarbeit sind gar nicht so ähnlich. > > Doch, natürlich. Extrem ähnlich. Ingenieursarbeit ist strukturierter, linearer, planbarer, hat viel mit Zahlen zu tun. Softwareentwicklung ist verschlungener, iterativer, kreativer, komplexer, hat mehr mit Strukturen und Abläufen zu tun. Aber solche Unterschiede ist dir zu subtil. > Mit "Softwareentwicklung" ist hier > natürlich nicht das Tagewerk von gehirnamputierten Codiersklaven > gemeint. Minderwertigkeitskomplexe? > >> Dass erfahrene >> Softwareentwickler automatisch zu Ingenieuren werden macht also wenig >> Sinn. > > Doch, das macht mindestens denselben Sinn, mit dem Handwerksmeister die > Fähigkeiten von frisch graduierten Ingenieuren passender Fachrichtung > erlangen (und weit, weit überschreiten können). Ich kenne rein zufällig einen Handwerksmeister der danach studiert hat. Der ist im Studium ganz schön ins Schlingern gekommen. Ist eben doch alles nicht so einfach.
Walter T. schrieb: > Es ist dann überflüssig, wenn es nachträglich geschrieben wurde. Wenn es > vorher geschrieben wurde, sieht es anders aus [...] > Wenn das andersherum gemacht wird, ist das ziemlich überflüssig. Weil ich es gerade offen habe zwei Beispiele:
1 | /** @brief Bruch kuerzen
|
2 | *
|
3 | * Das Ergebnis hat immer einen positiven Nenner.
|
4 | * @param[in] F Regulaerer Bruch (Nenner nicht Null!)
|
5 | * @return Bruch */
|
6 | frac64_t frac64_reduce(frac64_t F) { |
1 | /** @brief Bruch als Q16 approximieren
|
2 | *
|
3 | * Multiplikation mit Q16 entspricht trunkierender Division, nicht Rundung
|
4 | *
|
5 | * @param[in] F echter oder unechter regulaerer Bruch (Nenner nicht Null!)
|
6 | * @return Approximation in Q16 */
|
7 | int32_t frac32_toQ16(frac32_t F) { |
Nach den Kommentaren könnte hier wahrscheinlich jeder die Funktion so runterschreiben. Wenn man die Spec erst schreibt, wenn das Produkt fertig ist, ist das ja auch kein Wunder, dass das überflüssige Arbeit ist.
:
Bearbeitet durch User
Walter T. schrieb: > Dann schreibt man erst, was die Funktion machen soll und > benutzt das dann als Spezifikation. Oft ist das Runterschreiben > der Funktion selbst dann total einfach. Ja stimmt. In unserer Firma machen das die technischen Projektleiter in Form eines Wiki. Da wird jetzt nicht jede einzelne Methode spezifiziert, aber die Funktionen aus Business Sicht, als dass was von außen (z.B. via REST Interface und DB) sichtbar ist. Dann programmieren wir das runter und ergänzen anschließend das Wiki. Manchmal stehen im Code komische Sonderlocken wie:
1 | if (loginSucceeded) |
2 | {
|
3 | delay(1000); // ms |
4 | } |
5 | return accesstoken; |
Da ist es dann gut, wenn man den Link zum Wiki Artikel darüber schreibt, in dem erklärt wird, wer diesen Delay warum gefordert hat.
Stefan ⛄ F. schrieb: > c-hater schrieb: >> Tagewerk von gehirnamputierten Codiersklaven gemeint. > Gibt es diesen Job überhaupt in Echt? Leider ja und es wird immer mehr. > Muss nicht jeder Programmierer zumindest Teil-Konzepte selbst erstellen > und sich die Strukturen sowie Fehlerbehandlungs-Routinen ausdenken? Naja, natürlich sind auch diese Sklaven nicht völlig unfähig. Ist ungefähr das, was im Gewerbe die Facharbeiter/Gesellen sind. Natürlich können auch die was (inbesondere die mit Erfahrung) und sie verantworten durchaus auch oft kleinere Design-Entscheidungen. Aber genau das ist dann typisch auch das Problem in der realen Welt des Codiersklaventums. Sie bekommen oft nichtmal mehr die Chance, das "Große Ganze" kennen zu lernen, sondern werden absichtlich auf den kleinen Teil reduziert, den sie zu bearbeiten haben. Es würde nämlich schlicht zuviel ihrer Zeit kosten, wenn sie sich in die Gesamtproblematik eindenken dürften. Das ergibt dann im Endeffekt bezüglich der Gesamtlösung oft dramatisch suboptimalen Code. Naja, bei praktisch allen derzeitigen Softwaremonstern kann man sich anschauen, wozu dieser Ansatz führt... Aber die Entwicklug war immerhin vergleichweise billich. Das freut allerdings allein den Boss der Entwicklerfirma, und ggf. auch noch deren Aktionäre. Es freut aber nicht die Anwender, nicht die Entwickler und nichtmal die Codiersklaven...
1 | TASK (blink) |
2 | wr_pin(12,30,w_dn); |
3 | t_Wait_cs(T_(para)); |
4 | task_until(0) |
EAF schrieb: > Dutzendfach im täglichen Betrieb.... > Tuts perfekt. > > Beispiel, ein weiteres BlinkWithoutDelay: >
1 | > #pragma once |
2 | >
|
3 | > #include <CooperativeTask.h> |
4 | >
|
5 | >
|
6 | > class BlinkTask: public Task |
7 | > { |
8 | > protected: |
9 | > const byte pin; |
10 | > const unsigned long interval; |
11 | >
|
12 | > public: |
13 | > BlinkTask(const byte pin,const unsigned long interval): |
14 | > pin(pin), |
15 | > interval(interval) |
16 | > { |
17 | > } |
18 | > ... |
19 | >
|
... gerade wenn blinkende LED "Dutzendfach im täglichen Betrieb" genutzt werden ist der Aufwand für jede LED eine eigene Klasse zu schreiben viel Arbeit ....
Stefan schrieb: > blinkende LED "Dutzendfach im täglichen Betrieb" genutzt Bla bla..... Als wenn die Welt nur aus blinkenden LEDs besteht. Sie ist nur eine Beispiel für einen einfachen Automaten Stefan schrieb: > ist der Aufwand für jede LED eine eigene Klasse zu schreiben viel > Arbeit .... Ja ja....
1 | BlinkTask blinker[]{// {pin,interval} |
2 | {13,8000}, |
3 | {4,2000}, |
4 | {7,5000}, |
5 | };
|
Zudem können jederzeit mit new neue Tasks erzeugt werden. Aber wem sage ich das......
EAF schrieb: > Zudem können jederzeit mit new neue Tasks erzeugt werden. aber halt nicht so einfach programmiert werden. dass EAF eine Version bei wokwi.com hochladen kann, um bspw. beim Thema "Wie macht man Lichteffekte?" helfen zu können. EAF schrieb: > Aber wem sage ich das...... .. sei einfach mal mutig
Beitrag #6802352 wurde von einem Moderator gelöscht.
Beitrag #6802357 wurde von einem Moderator gelöscht.
Beitrag #6802363 wurde von einem Moderator gelöscht.
Gerade passiert genau das, was ich oben nannte: Jedes Team hat andere Bedürfnisse.
Beitrag #6802368 wurde von einem Moderator gelöscht.
Beitrag #6802379 wurde von einem Moderator gelöscht.
Beitrag #6802390 wurde von einem Moderator gelöscht.
c-hater schrieb: > Aber die Entwicklug war immerhin vergleichweise billich. Das freut > allerdings allein den Boss der Entwicklerfirma, und ggf. auch noch deren > Aktionäre. Als ich jung war hörte ich von den Wahnsinnsfirmen in Amiland, die ihre richtig guten Leute vor Besuchern, Kunden, Aktionären im Keller versteckt hielten, da diese weder Anzug, weißes Hemd ect. bei der Arbeit trugen, ansonsten auch eher ungenießbar im Umgang waren, aber Spitzenleistungen brachten und Spitzengehälter kassieren sollten...sowas wollte ich da auch mal werden :-) Und ich denke sogar, dass jemand, der in dieses Bild passt, auch 500 "GoTo" in 1000 Zeilen Programm unterbringt! Und meiner M. n. war bei Fortran damals das berühmte Programm "Schmierpapier" d a s Highlight. Hochgeschwindigkeitsdrucker im Rechenzentrum, wo auch der cleverste Operator so einen fehlerhaften Job kaum unter 2cm Druckerpapier gestoppt bekam. Wenn der "Programmierer" dann am nächsten Tag seinen Ausdruck abholen wollte, dann spielten sich da Dramen ab, die nur das Leben schreiben kann! Gruß Rainer
Walter T. schrieb: > Wie lassen sich "neue" Implementierungstechniken kennenlernen? Da haben sich wirklich Adams Dunkels Protothreads als Beispiel Lesestoff für das von Knuth ('literate programming'/TeX/MAD-Magazine) entwickelte Makro-Konzept als abwechslungsreicher Lesestoff herausgestellt: Original-Makros:ANSI-C von Adam Dunkel https://web.archive.org/web/20051013062233/http://www.sics.se/~adam/pt/ für GCC-C(neue/alte Implementierungstechnik: computed goto) https://github.com/LarryRuane/protothread dt.Aufsatz in C: http://stefanfrings.de/net_io/protosockets.html Kurzvariante mit dem sprachlichen Teil des Konzepts(ohne Verwaltung der Task) https://forum.arduino.cc/t/projekt-multitasking/399677 Es gibt bei µC.net zig Projekte mit dem gleichen Thema und unterschiedlichen Quelltexten d.h. es kann durchaus sinnvoll sein sich einige durchzulesen, um einen passenden Stil zu finden ("Lauflicht"/"Lightshow"/.. waren vor kurzem aktuell). - handwerklich programmieren: für gute Projekte ist ein Team notwendig, das die Verantwortung übernimmt (ohne Team können Projektleiter häufig nur mekkern und belasten Hobbyisten) - künstlerisch programmieren: vor allem schwierige Suche nach einem Thema (und Experimente/Fehlschläge beim eigenen Stil) - in der Wirtschaft ist ein (Software) Architekt mit UML üblicherweise an Projekten beteiligt d.h. KEIN Hobby weil so'n Architekt ziemlich teuer ist.
Beitrag #6802703 wurde von einem Moderator gelöscht.
Beitrag #6802717 wurde von einem Moderator gelöscht.
Beitrag #6802722 wurde von einem Moderator gelöscht.
Beitrag #6802740 wurde von einem Moderator gelöscht.
Beitrag #6802754 wurde von einem Moderator gelöscht.
Beitrag #6802773 wurde von einem Moderator gelöscht.
Beitrag #6802778 wurde von einem Moderator gelöscht.
Beitrag #6802793 wurde von einem Moderator gelöscht.
Beitrag #6802816 wurde von einem Moderator gelöscht.
Beitrag #6802822 wurde von einem Moderator gelöscht.
Einer schrieb: > Man kann's mit der Löscherei auch übertreiben. sorry dürfte mein Fehler (erwähnung meiner aktuellen Erst-Religion:Makro-ASM) gewesen sein, obwohl es hier um C geht) Meine Meinung, dass Makros wie von Adam Dunkel auch eine Bereicherung für Hobby- Autoren sein können, ist unabhängig von der Grundsprache. Der Bann, von dem der Arduino-Botschafter in seiner undeutlichen Sprache berichtet hat, stellt auch klar, dass basic gegen die dortige Weltanschauung steht.
Angelehnt an die Überschrift des Threads werfe ich mal ein Lesestoffbeispiel ein: Die Z80 Emulation von Frank: https://github.com/ukw100/STECCY/blob/main/src/z80/z80.c So eine Emulation hat viele Herausforderungen, vor allen Dingen Geschwindigkeit. Deshalb sieht man viele
1 | static inline ... |
Was mich an dem Code stört, sind die vielen Includes am Anfang, die Abhängigkeiten zu anderen Modulen erzeugen und damit den Code wenig transportabel machen.
Markus schrieb: > Die Z80 Emulation von Frank: > https://github.com/ukw100/STECCY/blob/main/src/z80/z80.c Beitrag Nr. 156 passt wieder zum Thema. Danke! Danke auch für das Beispiel im Speziellen. Ich hatte noch nie Anlass, mir ein Emulator-Projekt von Nahem anzugucken. Markus schrieb: > Was mich an dem Code stört, sind die vielen Includes am Anfang Was mich noch mehr stört, ist dass am Anfang der Datei eine Beschreibung fehlt, was sie überhaupt machen soll. Aber vielleicht tue ich ihr da Unrecht und es liegt nur am merkwürdigen "Einsprungpunkt" direkt in die .c-Datei und im Kontext des GIT-Repositorys passt das. Das muss ich mir mal in Ruhe zu Gemüte führen.
:
Bearbeitet durch User
Walter T. schrieb: > Beitrag Nr. 156 passt wieder zum Thema. Das Problem passiert halt wenn Hilfesuchende ihr Thema "Lesestoff" im Forum "digitale Elektronik" posten, anstatt im: https://www.mikrocontroller.net/forum/offtopic Adam Dunkels Protothreads sind halt nur nützlich wenn man bspw. bei einem 32CH-PWM-Board aus dem Bereich der digitalen Elektronik qualifiziert helfen möchte. Bezahlte Diskutierer können nur von ihren Erkenntnissen berichten: Beitrag "Re: Wie macht man solche Lichtmodes? Lauflicht, PWM und Co" und mekkern halt Menschen an die wirklich programmieren lernen möchten.
Walter T. schrieb: > Es wird wohl auf das Lesen von Quelltext hinauslaufen. Das Problem: Wie > findet man guten Quelltext zum Lesen? In Foren o.Ä. findet man ja > hauptsächlich Schnipsel und zweifelhafte Fälle. google ist Dein bester Freund :-) damit solltest Du schon umgehen können, dann wirst Du auch fündig. Du findest vollständige Programme in Unmengen - die sind dann allerdings unkommentiert und teilweise auch schlecht programmiert. Aufdröseln und den Quelltext verstehen mußt Du schon selbst. Walter T. schrieb: > Und bitte auch auf lesbare Teile beschränken. "Der Linux > Kernel" ist so groß, dass das keiner lesen kann. Aber überschaubare > Teile wären super. keine Ahnung was Du vorhast bzw. wonach Du überhaupt suchst? Für Codesnipsel und "Teilausschnitte" gibt es doch gute und schlechte Bücher in schier unendlicher Anzahl?
Progbit schrieb: > google ist Dein bester Freund :-) Ein absolut hochwertiger Tipp! Beinahe gleichauf mit dem Tipp "Amazon", falls jemand ein gutes Buch zu einem spefizischen Thema sucht, weil es da ja recht viele Bücher gebe.
:
Bearbeitet durch User
Progbit schrieb: > keine Ahnung was Du vorhast bzw. wonach Du überhaupt suchst? das Interesse an Teilen des Linux-Kernels","Teil X der OpenSSL2-Bibliothek", etc. könnte darauf hindeuten, dass er sich bspw. an GeckOS: https://de.wikipedia.org/wiki/GeckOS beteiligen möchte. GeckOS unterstützt bereits präemptives Multitasking und Multithreading, Signale und Semaphore, sowie einige Unix-Shell-Funktionen (z. B. Piping).
Dirk schrieb: > [...] dass er sich bspw. an GeckOS: > https://de.wikipedia.org/wiki/GeckOS > beteiligen möchte. Auch wenn gemäß dem Fragebogen aus dem recht weit oben empfohlenen Buch das Ergebnis herauskam: "Programmieren Sie weiter am Linux Kernel oder was Sie sonst so machen", gehe ich davon aus, dass es sich lediglich um den bekannten schnodderigen Schreibstil Frau Passigs und nicht etwa um einen ernstgemeinten Tipp handelt.
:
Bearbeitet durch User
Walter T. >>https://github.com/ukw100/STECCY/blob/main/src/z80/z80.c >Was mich noch mehr stört, ist dass am Anfang der Datei eine Beschreibung >fehlt, was sie überhaupt machen soll. Aber vielleicht tue ich ihr da >Unrecht und es liegt nur am merkwürdigen "Einsprungpunkt" direkt in die >.c-Datei und im Kontext des GIT-Repositorys passt das. Das muss ich mir >mal in Ruhe zu Gemüte führen. >merkwürdigen "Einsprungpunkt" Ja, der merkwürdige Einsprungpunkt ist in Zeile 7730 und die Funktion heißt einfach z80(). Ich glaube, so sollte man es definitiv nicht machen. In dem File ist die Emulation des Prozessors und des gesamten Computer gemischt. Interessant ist auch, dass die Opcodes über eine Switch/Case Entscheidung ausgeführt werden, dass kann bei 256 Opcodes ziemlich langen gehen. Andere Emulatoren verwenden meines Wissens nach Tabellen mit Funktionpointern. Damit kann man dann schnell einfach über den Index springen. Hier hat ein Student eine Arduino-Library für die Z80 Emulation geschrieben: https://github.com/MohammedRashad/ArduZ80/blob/master/ArduZ80.cpp Die ist aber ziemlich schlecht verwendbar und hat Funktionsaufrufen zu den CPP-println des Arduino Frameworks drinn. Wenn man in einen mit Sicherheit professionell geschriebenen Code schauen möchte, kann man den Linux-Kernel nehmen. https://github.com/torvalds/linux/blob/master/kernel/entry/common.c Interessant finde ich hier, dass es so gut wie keine Kommentare im Code gibt. Das hätte ich von einem so viel verwendeten OpenSource Projekt nicht erwarted.
Walter T. schrieb: >>> Eigentlich interessieren mich bewährte Techniken, >>> auf die ich einfach noch nicht gestoßen bin. >> Fragebogen GeckOS zum BUCH >> - präemptives Multitasking: Bewährte Technik (ja/nein)? >> - Multithreading: Bewährte Technik (ja/nein)?, >> - Signale und Semaphore:Bewährte Technik (ja/nein)? >> - Unix-Shell-Funktionen (z. B. Piping):Bewährte Technik (ja/nein)?. > Auch wenn gemäß dem Fragebogen aus dem recht weit oben empfohlenen Buch > das Ergebnis herauskam: "Programmieren Sie weiter am Linux Kernel oder > was Sie sonst so machen", gehe ich davon aus, dass es sich lediglich um > den bekannten schnodderigen Schreibstil Frau Passigs und nicht etwa um > einen ernstgemeinten Tipp handelt. Passigs wird fürs diskutieren so bezahlt wie "gute Programmierer": Beitrag "Re: Quelltext: Lesestoff gesucht"
Markus schrieb: > Interessant finde ich hier, dass es so gut wie keine Kommentare im Code > gibt. Das hätte ich von einem so viel verwendeten OpenSource Projekt > nicht erwarted. Ja, beeindruckend:
1 | wk [ /usr/src/linux-4.18.5 ]# find . | xargs grep -i fuck | wc -l |
1 | 29 |
Gruss WK
Das Fazit von all den Kommentaren ist also... - such keinen Code, er ist eh nichts. - C ist ein Wettbewerb sich das Leben selbst schwer zu machen - Das Motto, wer schiesst sich und einem Nachfolger schneller in den Fuss. - Das Leben ist zu kurz fuer C, mach was anderes. Es gibt Buecher in anderen Sprachen zu Datenstrukturen, und Loesungsansaetzen, sogenannten Designpattern.
:
Bearbeitet durch User
Pandur S. schrieb: > Das Fazit von all den Kommentaren ist also... ... ausgehend von einem Literaturkenner der vom Schreibstil von Frau Passig (BDSM Berlin; "Techniktagebuch") berichten kann er sei schnodderig: "Die meiste Literatur widmet sich entweder abstrakten Konzepten oder ist an Anfänger gerichtet." ==> ganz präzise konnte Walter "bewährte Techniken" ja nicht nennen. > - such keinen Code, er ist eh nichts. gaaanz bisschen Code hilft häufig bei der Programmierung > - C ist ein Wettbewerb sich das Leben selbst schwer zu machen eigentlich ist so eine Mittelsprache 0 geeignet für einen Solo-Wettbewerb: - sportlich wird ASM gewertet - künstlerisch stehen mit Arduino/Basic/Pascal/Makros/UML so viele geeignetere Sprachen zur Verfügung, dass C praktisch chancenlos ist (als Team/Industrie-Sprache durchaus geeinet) > Das Motto, wer schiesst sich und einem Nachfolger schneller in den > Fuss. der heutigen selfpublisch-Generation fehlt halt so was wie ein C64 der einen nicht gleich anmekkert, nur weil der Multitasking-kernel wie bei AVR kleiner als 4kb ist (1999): http://www.6502.org/users/andre/osa/index.html d.h. früher waren 8-bit Computer praktisch schon im Kinderzimmer > Das Leben ist zu kurz fuer C, mach was anderes. zumindest sollten die 24hours die Zeit vor und nach "17:00" unterscheiden lernen, damit sie nicht ohne die Hilfe ihres Software-Architekten weiter diskutieren müssen > Es gibt Buecher in anderen Sprachen zu Datenstrukturen, und > Loesungsansaetzen, sogenannten Designpattern. im µC Hobby sind mEn. größere Datenstrukturen eher im biologischen Bereich zu organisieren sodass eher die Abweichung von Designpattern interessant ist
Pandur S. schrieb: > Das Fazit von all den Kommentaren ist also... > - such keinen Code, er ist eh nichts. > - C ist ein Wettbewerb sich das Leben selbst schwer zu machen Zu 1: Ja. Fremder Code ist problematisch. Zu 2: Nöö. Programmieren, ist gießen von Gedanken, in Speicher! Das Abbild der Denke. Und mehr kann man auch aus gebrauchten Programmen nicht herauslesen..... Man sieht daran/darin, eben nicht, die eigenen Bedürfnisse, Freuden und Fähigkeiten.
Walter T. schrieb: > Ein absolut hochwertiger Tipp! Beinahe gleichauf mit dem Tipp "Amazon", > falls jemand ein gutes Buch zu einem spefizischen Thema sucht, weil es > da ja recht viele Bücher gebe. Der Tip ist auch super und hat mit Amazon nichts zu tun. Bei Amazon mußt Du zahlen, bei Google kannst Du suchen und finden ... wenn man denn weiß, was macht überhaupt sucht, was Du eben noch nicht weißt :-) Der NACHTEIL bei den gefundenen Quelltexten wird die Kommentierung sein, die fehlt zu 90% - da brauchst Du dann ein Lehrbuch und dann kannst Du bei Amazon das hoffentlich Richtige kaufen :-)
Pandur S. schrieb: > Das Fazit von all den Kommentaren ist also... > - such keinen Code, er ist eh nichts. er sucht eben falsch, das ist sein Problem. > - C ist ein Wettbewerb sich das Leben selbst schwer zu machen aber was ist dann C++ ... die Zerstörung des Lebens :-) > - Das Motto, wer schiesst sich und einem Nachfolger schneller in den > Fuss. > - Das Leben ist zu kurz fuer C, mach was anderes. wenn er glaubt es zu können, es das schon mal ein Ansatz. > Es gibt Buecher in anderen Sprachen zu Datenstrukturen, und > Loesungsansaetzen, sogenannten Designpattern. klar, alles schön theoretisch mit vielen Codeschnipseln - junk Bücher für Möchtegern-Nerds.
Markus schrieb: > Interessant ist auch, dass die Opcodes über eine Switch/Case > Entscheidung ausgeführt werden, dass kann bei 256 Opcodes ziemlich > langen gehen. Nach meinem Kenntnisstand ist die Besonderheit von switch/case, dass ab einer gewissen Größe jeder case gleich lange dauert, im Gegensatz zu einer if-else-if Kette. Aus großen switch/case macht der Compiler eine Sprungtabelle.
Stefan ⛄ F. schrieb: > ist die Besonderheit von switch/case, dass jeder case gleich lange > dauert, Nein. Stefan ⛄ F. schrieb: > Aus großen switch/case macht der Compiler eine Sprungtabelle. Geht nicht wenn die Werte nicht kontinuierlich sind. Der Compiler macht ggf. auch bedingte Sprünge, ggf. mit binärer Suche. Dadurch dauern die Fälle ggf. unterschiedlich lang.
Programmierer schrieb: >> Aus großen switch/case macht der Compiler eine Sprungtabelle. > > Geht nicht wenn die Werte nicht kontinuierlich sind. Klar geht das. Ist eine Entscheidung, wann der Compiler was macht. Die nicht kontinuierlichen Werte sind dann halt mit "default" belegt (und wenn es keinen "default"-Label gibt, springt er hinter den switch). Die Entscheidung wird natürlich durch die Optimierungseinstellungen verändert: will ich auf Speicherplatz optimieren, wird if/else ausgeführt, sofern das von der Schätzung her Codegröße spart. Optimiere ich auf Ausführungszeit (-O3 bei GCC oder Clang), dann spielt die Codegröße keine Geige, und es wird sehr schnell zur Tabelle gegriffen.
Jörg W. schrieb: > Optimiere ich auf Ausführungszeit (-O3 bei GCC oder Clang), dann spielt > die Codegröße keine Geige, und es wird sehr schnell zur Tabelle > gegriffen. Was wenn man 2 Werte hat, 0 und 2^64-1? Das wäre eine sehr große Tabelle.
Jörg W. schrieb: > Optimiere ich auf Ausführungszeit (-O3 bei GCC oder Clang), > dann spielt die Codegröße keine Geige, und es wird sehr > schnell zur Tabelle gegriffen. Programmierer schrieb: > Was wenn man 2 Werte hat, 0 und 2^64-1? Das wäre eine sehr große > Tabelle. Dann wohl eher nicht. "schnell" bedeutet nicht "immer".
Programmierer schrieb: > Was wenn man 2 Werte hat, 0 und 2^64-1? Dann könnte man vorher 1 addieren, hat man wieder eine Tabelle. :-) Klar, es ging hier nicht um pathologische Fälle, sondern wimre. um einen 8-Bit-Wert, der zu decodieren ist. Aber bitteschön:
1 | #include <stdint.h> |
2 | int something(uint64_t x) |
3 | {
|
4 | switch(x) { |
5 | case 0: |
6 | return 42; |
7 | |
8 | case 13: |
9 | return 10; |
10 | |
11 | case 14: |
12 | return 11; |
13 | |
14 | case 15: |
15 | return 8; |
16 | |
17 | case 21: |
18 | return 9; |
19 | |
20 | case 0xffffffffffffffffULL: |
21 | return 21; |
22 | |
23 | default:
|
24 | return 0; |
25 | }
|
26 | }
|
1 | .text |
2 | .file "foo.c" |
3 | .globl something # -- Begin function something |
4 | .p2align 4, 0x90 |
5 | .type something,@function |
6 | something: # @something |
7 | .cfi_startproc |
8 | # %bb.0: |
9 | pushq %rbp |
10 | .cfi_def_cfa_offset 16 |
11 | .cfi_offset %rbp, -16 |
12 | movq %rsp, %rbp |
13 | .cfi_def_cfa_register %rbp |
14 | addq $1, %rdi |
15 | cmpq $22, %rdi |
16 | ja .LBB0_7 |
17 | # %bb.1: |
18 | movl $42, %eax |
19 | jmpq *.LJTI0_0(,%rdi,8) |
20 | .LBB0_6: |
21 | movl $21, %eax |
22 | popq %rbp |
23 | .cfi_def_cfa %rsp, 8 |
24 | retq |
25 | .LBB0_7: |
26 | .cfi_def_cfa %rbp, 16 |
27 | xorl %eax, %eax |
28 | .LBB0_8: |
29 | popq %rbp |
30 | .cfi_def_cfa %rsp, 8 |
31 | retq |
32 | .LBB0_2: |
33 | .cfi_def_cfa %rbp, 16 |
34 | movl $10, %eax |
35 | popq %rbp |
36 | .cfi_def_cfa %rsp, 8 |
37 | retq |
38 | .LBB0_3: |
39 | .cfi_def_cfa %rbp, 16 |
40 | movl $11, %eax |
41 | popq %rbp |
42 | .cfi_def_cfa %rsp, 8 |
43 | retq |
44 | .LBB0_4: |
45 | .cfi_def_cfa %rbp, 16 |
46 | movl $8, %eax |
47 | popq %rbp |
48 | .cfi_def_cfa %rsp, 8 |
49 | retq |
50 | .LBB0_5: |
51 | .cfi_def_cfa %rbp, 16 |
52 | movl $9, %eax |
53 | popq %rbp |
54 | .cfi_def_cfa %rsp, 8 |
55 | retq |
56 | .Lfunc_end0: |
57 | .size something, .Lfunc_end0-something |
58 | .cfi_endproc |
59 | .section .rodata,"a",@progbits |
60 | .p2align 3 |
61 | .LJTI0_0: |
62 | .quad .LBB0_6 |
63 | .quad .LBB0_8 |
64 | .quad .LBB0_7 |
65 | .quad .LBB0_7 |
66 | .quad .LBB0_7 |
67 | .quad .LBB0_7 |
68 | .quad .LBB0_7 |
69 | .quad .LBB0_7 |
70 | .quad .LBB0_7 |
71 | .quad .LBB0_7 |
72 | .quad .LBB0_7 |
73 | .quad .LBB0_7 |
74 | .quad .LBB0_7 |
75 | .quad .LBB0_7 |
76 | .quad .LBB0_2 |
77 | .quad .LBB0_3 |
78 | .quad .LBB0_4 |
79 | .quad .LBB0_7 |
80 | .quad .LBB0_7 |
81 | .quad .LBB0_7 |
82 | .quad .LBB0_7 |
83 | .quad .LBB0_7 |
84 | .quad .LBB0_5 |
85 | # -- End function |
86 | .ident "FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)" |
87 | .section ".note.GNU-stack","",@progbits |
88 | .addrsig |
Wie du siehst, macht der Compiler genau das, was ich vermutet habe: er addiert da einfach mal 'ne 1 zuerst, danach hat er wieder eine "schöne" Tabelle.
:
Bearbeitet durch Moderator
>Wie du siehst, macht der Compiler genau das, was ich vermutet habe: er >addiert da einfach mal 'ne 1 zuerst, danach hat er wieder eine "schöne" >Tabelle. Das finde ich jetzt mal richtig lehrreich. Danke :-)
Beitrag #6804336 wurde von einem Moderator gelöscht.
Beitrag #6804347 wurde vom Autor gelöscht.
Beitrag #6804376 wurde von einem Moderator gelöscht.
Beitrag #6804424 wurde von einem Moderator gelöscht.
Beitrag #6804427 wurde von einem Moderator gelöscht.
Beitrag #6804436 wurde von einem Moderator gelöscht.
Beitrag #6804461 wurde von einem Moderator gelöscht.
Beitrag #6804472 wurde von einem Moderator gelöscht.
Beitrag #6804480 wurde von einem Moderator gelöscht.
Beitrag #6804502 wurde von einem Moderator gelöscht.
Beitrag #6804503 wurde von einem Moderator gelöscht.
Beitrag #6804515 wurde von einem Moderator gelöscht.
Mein Gott, was hätte man sich in der Zeit, wo ihr euch mal wieder Nettigkeiten um die Ohren haut, für interessante Sachen suchen und finden können. Und es erstaunt mich immer wieder, dass auf so eine - für mich alberne - Frage eines TO so viele Beiträge auflaufen! Es scheint ja viele Leute sowas wie "Ästhetik im Sandkasten" brennend zu interessieren. Wenn ich ein Problem nicht lösen kann, dann werfe ich heutzutage die Suchmaschine an und finde meist auch was. Dann freue ich mich erst mal und versuche es in mein Progrämmchen einzuarbeiten. Das gelingt halt so gut, wie ich den Findling verstanden habe. Später kommen ab und zu dann noch Feinheiten wie Schnelligkeit dazu...muß aber nicht und schon gar nicht , weil ich's können will... Gruß Rainer
Rainer V. schrieb: > Wenn ich ein Problem nicht lösen kann, dann werfe ich > heutzutage die Suchmaschine an und finde meist auch was. exakt genauso ist es. Rainer V. schrieb: > Dann freue ich > mich erst mal und versuche es in mein Progrämmchen einzuarbeiten. Das > gelingt halt so gut, wie ich den Findling verstanden habe. da scheint er Verständnis-Schwierigkeiten zu haben ... nur das ist dann sein persönliches Problem, das erfordert eben viel Zeit, weil einiges mangelhaft und vieles nur ausreichend erklärt wird. Gerade wenn es schwierig wird, schmieren z.B. auch viele Buchautoren ab ... da muß man schon selber Recherche betreiben.
Beitrag #6804585 wurde von einem Moderator gelöscht.
Beitrag #6804661 wurde von einem Moderator gelöscht.
Beitrag #6804699 wurde von einem Moderator gelöscht.
Programmierer schrieb: > ISBN 978-0201633610 Das Buch "Design Patterns. Elements of Reusable Object-Oriented Software." von Gamma, Helm et al. habe ich mir ausgeliehen und etwas drin gelesen. Es wird wohl angelesen zurückgehen. Ich behaupte nicht, dass es schlecht ist, aber es passt überhaupt nicht zum Thema. Schon in der Einleitung heißt es sinngemäß: "Treiber und GUI werden nicht behandelt" und das Ganze ist auch definitiv auf eine objektorientierte Sprache gemünzt. Nur ist gerade das Zweite (GUI) der Teil, der mich am meisten interessiert, weil es da am schwierigsten ist Übersicht hineinzubekommen, und in C C++ nachzubauen wird die Sache auch nicht übersichtlicher machen. Und "kurz vor Ende" eines Projekts die Programmiersprache zu wechseln ist eine schlechte Idee. Eine neue Programmiersprache probiert man mit einem nagelneuen Mini-Projekt aus. Ansonsten habe ich mir das Buch mal vorgemerkt für später.
:
Bearbeitet durch User
Walter T. schrieb: > Nur ist gerade das Zweite (GUI) der Teil, der mich am > meisten interessiert, weil es da am schwierigsten ist Übersicht > hineinzubekommen, und in C C++ nachzubauen wird die Sache auch nicht > übersichtlicher machen. Mit anderen Worten Du suchst eine GUI zu C und findest nichts? Dann google mal mal nach SDL oder GTK+ und schon wirst Du fündig. Alles vorhanden, einarbeiten mußt Du Dich selbst. Zusätzlich kannst Du natürlich fehlende Headerdateien unter Linux oder Mac einbinden, auch das geht, dauert dann etwas. Oder willst Du selber eine GUI schreiben? Was Du eigentlich willst, bleibt leider unklar.
Nico T. schrieb: > Ich finde den Source-Code von Chibios lesenswert. Er arbeitet sich mit > objektorientiertem C durch sein RTOS. Dem würde ich zustimmen, wobei mir der Source-Code persönlich etwas "Makro-lastig" ist. Er wird aber seine Gründe dafür haben. Um gerade beim Thema RTOS zu bleiben, werfe ich hier mal noch Nuttx ein und wenn es etwas anwendungsorientiertes sein soll, dann das Pixhawk-Projekt (PX4), welches auf Nuttx basiert. Der Bootloader von PX4 nutzt wiederum ChibiOS ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.