für objektorientertes C musst ihr euch GTK anschauen. https://docs.gtk.org/gobject/tutorial.html
Progbit schrieb: > Was Du eigentlich willst, bleibt leider unklar. Bei knapp 200 Beiträgen vergisst man mal schnell das Eröffnungsposting. Deswegen paraphrasiere ich das mal wieder: "Welchen Quelltext (in C), den ihr nicht selbst geschrieben habt, findet ihr absolut lesenswert? Beispiele zu µC und GUI interessieren mich besonders." Christopher J. schrieb: > 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, Definitiv eine der besten Vorstellungen bis jetzt. Die Z80-Emulation ist auch interessant.
:
Bearbeitet durch User
Walter T. schrieb: > Bei knapp 200 Beiträgen vergisst man mal schnell das Eröffnungsposting. > Deswegen paraphrasiere ich das mal wieder: > > "Welchen Quelltext (in C), den ihr nicht selbst geschrieben habt, findet > ihr absolut lesenswert? Beispiele zu µC und GUI interessieren mich > besonders." Du scheinst wirklich ein ernsthaftes Problem mit Google zu haben ?! Eines von 1000 Beispielen: https://github.com/shreejilucifer/Chess-In-C/blob/master/CHESSPR.C
Progbit schrieb: > Du scheinst wirklich ein ernsthaftes Problem mit Google zu haben ? Seit wann geben Suchmaschinen eine "Ich finde das lesenswert"-Bewertung aus?
Jörg W. schrieb: > Seit wann geben Suchmaschinen eine "Ich finde das lesenswert"-Bewertung > aus? wenn er das "lesenswert" nicht selbst beurteilen kann, dann sollte er sich ein Buch kaufen - wie jeder Anfänger.
Progbit schrieb: > Du scheinst wirklich ein ernsthaftes Problem mit Google zu haben ?! > Eines von 1000 Beispielen: > https://github.com/shreejilucifer/Chess-In-C/blob/master/CHESSPR.C Progbit schrieb: > wenn er das "lesenswert" nicht selbst beurteilen kann, dann sollte er > sich ein Buch kaufen - wie jeder Anfänger. Wow. Das fällt ja schon in die merkwürdige Kategie "nicht jeder Mensch besteht den Turing-Test".
Progbit schrieb: > wenn er das "lesenswert" nicht selbst beurteilen kann, dann sollte er > sich ein Buch kaufen Es ging wohl zu keinem Zeitpunkt in diesem Thread darum, das gesamte Internet nach C-Quelltexten abzugrasen um diese dann zu beurteilen. Die Frage war ganz eindeutig nach Empfehlungen, und wenn man keine hat – nun, dann braucht man hier auch nichts zu schreiben.
Jörg W. schrieb: > Es ging wohl zu keinem Zeitpunkt in diesem Thread darum, das gesamte > Internet nach C-Quelltexten abzugrasen um diese dann zu beurteilen. Die > Frage war ganz eindeutig nach Empfehlungen, und wenn man keine hat – > nun, dann braucht man hier auch nichts zu schreiben. eine Empfehlung zum Quelltext habe ich doch genannt - eine von vielen! Muß ich den Link wiederholen? Muß da neben dem Quelltext ein Premium-Sternchen oder Rezensionen wie Amazon stehen, damit es eine Empfehlung ist ???! Empfehlung zum selber lernen versteht sich! Wer das nicht kann oder will, der soll sich ein Buch bei Amazon kaufen, da gibt's dann auch Empfehlungen aka Rezensionen!
Zumindest bietet deine Tastatur offenbar ausreichend prellende Interpunktionstasten. Das ist ja schon mal was. Allerdings wohl nicht das, was Nicolas sucht.
Jörg W. schrieb: > Allerdings wohl nicht das, was Nicolas sucht. ... und genau dazu sollte er sich mal äußern!
Hallo, Progbit schrieb: > ... und genau dazu sollte er sich mal äußern! hat er doch getan: Walter T. schrieb: > 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.) > ... > Das Problem: Wie findet man guten Quelltext zum Lesen? > ... > 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.) und > Ich habe die Frage mit Absicht in die Rubrik "Mikrocontroller" gestellt. > Das ist natürlich die Plattform, die mich am meisten interessiert. rhf
Roland F. schrieb: > hat er doch getan: > > Walter T. schrieb: > ... völlig pauschal! Was will er denn jetzt - den Quelltext oder ein Buch mit Erläuterungen zu den Codezeilen ... soll ihm am Ende jemand erklären wie man besser programmiert? :-) Mehr als Beispiele kann niemand bringen. Es gibt komplette Quelltexte und wirklich jeder kann sie finden - nur kapieren muß man es schon selber - und für Lernanleitungen in C gibt's nun mal Bücher mit Codeschnipseln und manchmal auch kompletten Quelltext im Anhang oder auf CD. Je nachdem was er will, muß er sich eben selbst in SDL oder GTK+ einarbeiten. Ist eben nicht so einfach, denn da wo es schwierig wird schmieren viele Bücher ab bzw. werden schwammig.
GTK+ und SDL sind wohl das Gegenteil von Software, die auf einem µC laufen. Zumindest SDL kenne ich mittlerweile ganz gut, und es ist für Windows und Linux recht gut, aber es hätte wenig Sinn, das auf den µC der Wahl zu portieren. Dort sind die Wege, Pixel und Nutzereingaben zu verarbeiten, deutlich anders. Du verstehst die Frage nicht. Das ist OK. Das Leben geht weiter! Du bekommst keine schlechte Note, wenn Du einfach nicht antwortest.
Besser programmieren? D.h. man hat etwas und will es verbessern? Dann ist es ein Fall fürs Refactoring. Dazu gibt es ja auch einiges (Bücher, youtube-Videos, Tutorial, etc..)
Walter T. schrieb: > Du verstehst die Frage nicht. Das ist OK. Das Leben geht weiter! Du > bekommst keine schlechte Note, wenn Du einfach nicht antwortest. Du mußt die Frage richtig formulieren und dann lautet sie: ICH such nur komplette Quelltexte für µC - sonst nichts, wo gibt's die nur ?
Ich kann Deine Verärgerung nachvollziehen. Ich habe noch eines dieser Benutzerkonten, wo man Threads ungestraft unkommentiert lassen kann. Wenn ich also eine Frage nicht verstehe, oder mir eine Diskussion nicht gefällt, oder das Ansinnen des Thread-Eröffners mich nervt oder mir das einfach alles auf den Geist geht, darf ich das Browser-Fenster einfach so schließen, ohne etwas geschrieben zu haben, ohne dass da irgendeine Kostenfalle lauert. Ich weiß nicht, ob diese Art von Kontos noch existiert, aber wenn, solltest Du Dir unbedingt so eines zulegen! Damals waren sie kostenlos, aber ich weiß nicht, wie das heute aussieht. Es macht alles viel entspannter. Man spart sich so viel unnötige Aufregung.
Walter T. schrieb: > .... Da hast du es dich aber fein und bequem, auf dem Mount Stupid eingerichtet.
Walter T. schrieb: > Es macht alles viel > entspannter. Man spart sich so viel unnötige Aufregung. da hast Du recht, ich habe übrigens auch kompletten Quellcode zu µC gefunden (war allerdings etwas schwieriger) und weil alles so entspannt ist, darfst Du auch mal suchen :-)
Auch jetzt noch sind die Beiträge, bis auf ganz wenige Ausnahmen, genau so unsinnig, wie es die Fragestellung provoziert. Im richtigen Leben hast du im Studium meinetwegen eine Literaturliste und in der Prüfung wird abgefragt, was man da finden kann. Später sind alle Möglichkeiten offen...was ganz Neues lernen, das Alte optimieren oder gar "ästhetisch" machen oder sich allgemein Gedanken machen über Programmierstile und wie sehe ich mich selbst in diesem Feld. All das macht man aber vorzugsweise mit sich allein aus und daher eignet sich diese Frage so nicht für die Öffentlichkeit...außer man liebt unendliches Geschwurbel...am Stammtisch wäre es immerhin nach dem fünften Bier beendet, aber so :-) Gruß Rainer
Rainer V. schrieb: > Auch jetzt noch sind die Beiträge, bis auf ganz wenige Ausnahmen, genau > so unsinnig Leider ja. Rainer V. schrieb: > wie es die Fragestellung provoziert. Zumindest scheint das ein erklecklicher Anteil hier so zu sehen. Meine Vermutung dazu habe ich oben ja schon geschrieben: Offensichtlich findet kaum ein Softwerker einen Quelltext (den er nicht selbst geschrieben hat) von sich aus "schön" oder "lesenswert". Im Gegensatz zu Ingenieuren, die die Ästhetik des Schaltplans auch so mal genießen können. Oben wurde mal angemerkt, dass das daran läge, das Quelltexte so kompliziert seien. Aber dann würde auch niemand mühselig einen fremdsprachigen Prosatext lesen. Oder 1000-Seiten-Romane. Oder gar Gleichungen. Dass bestimmte Gleichungen von hinreichend qualifizierten Lesern als schön empfunden werden, ist ja auch kein Geheimnis. Aber funktionale Ästhetik scheint in Software nicht zu existieren, oder zumindest bei den hiesigen Besuchern komplett unbekannt.
:
Bearbeitet durch User
Walter T. schrieb: > Dass bestimmte Gleichungen von hinreichend qualifizierten Lesern als > schön empfunden werden, ist ja auch kein Geheimnis. Du meinst doch eher, dass z.B. bestimmte mathematische Sätze, die einen durchaus komplizierten Sachverhalt auf den Punkt bringen, als elegant empfunden werden. Mein Lieblingsausdruck bei den Mathematikern: "Wie man sofort sieht..." und dann brauchst du vier Din-A-4 Seiten, um es zu sehen...Aber zwei CPU-Register kannst du nun mal nur addieren oder was die Maschine hergibt, aber was soll man daran bewundern? Nicht mal die berühmten alten Assemblerprogramme, die mit Opcodemanipulationen und Ähnlichem gearbeitet haben, hat man bewundert... höchstens fluchend gewürdigt... Gruß Rainer
Rainer V. schrieb: > Du meinst doch eher, dass z.B. bestimmte mathematische Sätze, die einen > durchaus komplizierten Sachverhalt auf den Punkt bringen, als elegant > empfunden werden. Nein, ich meine einige Gleichungen der Kontinuumsmechanik, denen eine gewisse Schönheit innewohnt. Aber das ist Betrachtungssache. Rainer V. schrieb: > Aber zwei CPU-Register kannst du nun mal nur addieren oder was > die Maschine hergibt Deswegen besteht der Trick ja darin, in einer Hochsprache wie C zu programmieren.
:
Bearbeitet durch User
Walter T. schrieb: > Deswegen besteht der Trick ja darin, in einer Hochsprache wie C zu > programmieren. Ich sehe da keinen Trick...die Hochsprache ist für mich nur eine Sammlung von meinetwegen Unterprogrammen, die du zusammenschustern kannst. Dabei setzt die jeweilige Hochsprache bestimmte Paradigmen um, wie Speicher optimieren und kompliziertere Sachen. Und dann kannst du in jeder Hochsprache so etwas wie elegant oder total holperig umsetzen. Das siehst du ja immer sofort an der Schelte für unsauberes Einrücken... Bei Gleichungen speziell in der höheren Physik ist es doch auch so, dass die kompakteste, also abstrakteste (falls so etwas gesagt werden darf) schön erscheint...letztlich stehen wir dann bei sowas wie E = m * c**2 oder z.B. bei den Maxwell-Gleichungen, aber das ist eben sehr subjektiv. Gruß Rainer
Walter T. schrieb: > Aber funktionale Ästhetik scheint in Software nicht zu existieren Donald E. Knuth vielleicht? Hab ihn aber nicht wirklich selbst gelesen. Im Allgemeinen ist man als Softwerker glücklich, wenn die Software die Aufgabe erfüllt und dabei auch noch lesbar ist. Zeit für viel mehr Ästhetik hat man selten. Beispiele für unleserlichen Code gibt es ohnehin genügend, so weiß man zumindest, wie man es nicht machen sollte. ;-)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Hab ihn aber nicht wirklich selbst gelesen. Wurden seine Bücher überhaupt von irgendjemanden gelesen? Er hat doch auch über die Algorithmen geschrieben: Von allen empfohlen - von keinem wirklich gelesen ;-) Bei TeX zahlte er wohl für jeden gefunden Fehler etwas Geld (als Anerkennung). Vielleicht wäre dieses Programm was für den Topicstarter ;-)
Walter T. schrieb: > Meine Vermutung dazu habe ich oben ja schon geschrieben: Offensichtlich > findet kaum ein Softwerker einen Quelltext (den er nicht selbst > geschrieben hat) von sich aus "schön" oder "lesenswert". Ist eigentlich überall so. Und nicht erst seit gestern. "Ich weiß, dass ich nichts weiß". (Sokrates) Nur ein Dummkopf hält sein Werk für das Beste.
Walter T. schrieb: > oder "lesenswert". Das ist was anderes. Du kannst auch fehlerhaften Code nehmen und daraus lernen. Oder nicht.
Nachdenklicher schrieb: > 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. Heute heisst das Exception... Ist noch schlimmer als goto, weil man nicht mal das Ziel kennt.
Walter T. schrieb: > Meine Vermutung dazu habe ich oben ja schon geschrieben: Offensichtlich > findet kaum ein Softwerker einen Quelltext (den er nicht selbst > geschrieben hat) von sich aus "schön" oder "lesenswert". Doch, guten Sourcecode gibt es immer wieder mal. Aber du machst es dir halt sehr, sehr einfach. Warum schaust du nicht einfach mal ein paar bekannte OS Projekte an, die dich von der Thematik her ansprechen? Python schaut gut aus, Perl genauso. RLab, Octave. Win32++, 4.3 BSD, FreeBSD, calc (Noll), lcc-compiler, mctl (Mity), Notepad2, PellesC, ReactOS, Wine, Stefan Kanthak libc, Tiny-C (Bellard), Rust, asmlib (Agner Fog), Windows ATL/WTL, MSCRT Source, SFML, godot (Game Engine), Windows Programming Petzold (Beispiele Buch), WinSpy++, ProcessHacker2, UltraDefrag, Scilab, Lua, x64dbg, dragon4 (Ryan Jacket) Illumis (OpenSolaris), Notepad++, glibc, Systemprogramming Beispiele (Hart), Numerical Recipies, WinVi, HexEdit (Catch22), Julia, MS Word 1.1a, Berkeley Spice2, Qucs, SuperSpice, awk (Kernighan), Windows 7 Classic Samples, Facebook folly Libs, etc, etc, etc. Du wirst dann schnell sehen, wie der Sourcecode strukturiert ist, und ob du damit klarkommst. Aber von dem Gedanken, dass du da mal kurz reinschaust, und die Erleuchtung hast, kannst du dich gleich verabschieden. Guter Sourcecode ist viel Arbeit, auch wenn man ihn nur verstehen will. Was ist guter Sourcecode (persöhnliche Rangliste)? * tut was er soll * ist Anwenderfreundlich * ist getestet, kommt auch mit Ausnahmefällen klar * ist (halbwegs) effizient und resourcenschonend * gute Datenstrukturen und Algorithmen * lässt sich auch noch in 10 Jahren compilieren, bzw. auch mit älteren Compilern heute compilieren. * passt ins Ecosystem rein * ist gut dokumentiert und damit für Quereinsteiger nachvollziehbar
udok schrieb: > Was ist guter Sourcecode (persöhnliche Rangliste)? > […] Dieser Rangliste würde ich mich direkt anschließen. Da ja auch konkrete Beispiele und explizit "embedded" und "GUI" gefragt waren: https://github.com/lvgl/lvgl
udok schrieb: > Aber du machst es dir halt sehr, sehr einfach. Du meinst nach guten Texten zu fragen, anstatt einfach alle Texte der Welt zu lesen und im Nachhinein zu entscheiden, welche ich gut finde? Unterm Strich stimmt das. Für letzteres fehlt mir die Zeit und die Lust. Man möge mir verzeihen. Der Durchschnittmensch hat eben nur knapp 80 Jahre Lebenszeit. Christopher J. schrieb: > https://github.com/lvgl/lvgl LVGL schaue ich mir heute abend mal an.
:
Bearbeitet durch User
Also mir hat der Thread aufgrund einiger Links schon geholfen - vielen Dank dafür an die wenigen produktiven Teilnehmer dieses Threads. Zu dem TE und seiner Erwartungshaltung sage ich lieber nichts ... da kann man eigentlich nur noch den Kopf schütteln.
Christopher J. schrieb: > Da ja auch konkrete Beispiele und explizit "embedded" und "GUI" gefragt > waren: > https://github.com/lvgl/lvgl Sieht interessant aus, wenngleich ich nicht so der Freund davon wäre, sowas wie das printf-Fahrrad nochmal zu erfinden.
1 Dollar schrieb: > Jörg W. schrieb: >> Hab ihn aber nicht wirklich selbst gelesen. > > Wurden seine Bücher überhaupt von irgendjemanden gelesen? Das sind keine Romane, sondern Nachschlagewerke oder Lehrbuecher. Ich brauchte mal Randomnumbers und Arithmetik. Und die Information Structures (Array, Lists, Tree, Stack, Queue u.s.w.) sollte man so oder so kennen. Fuer den "normalen" Leser ist die Mathematik in Knuths Buechern natuerlich eine Herausforderung. Das ist aber nichts, was sich nicht durch Durcharbeiten von Analysis I - III und Lineare Algebra I - III loesen laesst (Knuth hat das Problem auch erkannt, er hat einen kleinen Refresher geschrieben: L. Graham, Donald E. Knuth, Oren Patashnik, Concrete mathematics: a foundation for computer science, 657 p., Addison-Wesley). Das sind aber akademische Werke, der Nutzen bei der taeglichen Programmierung ist beschraenkt (bei mir ging es um Numerik bei Pre-IEEE 754-Zahlen, Verteilung von Zufallszahlen die ueberhaupt nicht zufaellig waren. Lang ist es her). Walter T. schrieb: > Du meinst nach guten Texten zu fragen, anstatt einfach alle Texte der > Welt zu lesen und im Nachhinein zu entscheiden, welche ich gut finde? > Unterm Strich stimmt das. Für letzteres fehlt mir die Zeit und die Lust. > Man möge mir verzeihen. Der Durchschnittmensch hat eben nur knapp 80 > Jahre Lebenszeit. Das ist das Privileg der Erfahrung: Wenn Du einen Text gelesen hast (und es ist Muell), brauchst Du keine Texte mehr von diesem Autor lesen. Der Umkehrschluss gilt auch. Und so baust Du Dir Deine eigene Bibliothek auf. Einige Jahre spaeter kannst Du Dir Deine Anfangsfrage beantworten :-) C'est tout pour aujourd'hui Th.
Thomas W. schrieb: > Das ist das Privileg der Erfahrung: Wenn Du einen Text gelesen hast (und > es ist Muell), brauchst Du keine Texte mehr von diesem Autor lesen. Autoren haben den Vorteil (oder je nach Sichtweise den Nachteil), dass jedes verlagsmäßig veröffentliche Buch ein Lektorat hinter sich hat. Was wiederum bedeutet, dass viele Bücher dankenswerterweise erst gar nicht veröffentlicht werden. Und trotzdem gibt es jede Menge Schund. Und bei Quelltext fehlt sogar dieser Selektionsmechanismus.
Du stellst dich ja an, wie der erste Mensch. Keiner schaut sich jeden Quellcode an, oder liest jedes Buch. Da muss dir schon wirklich sehr langweilig sein. Sondern man hat ein Problem oder Interesse, und dann schaut man, was es da schon gibt, und wie es andere gemacht haben. Damit hat man den Suchraum schon mal um > 99.9% reduziert. Dann schaut man, was davon brauchbar ist. Meist bleiben dann ein oder zwei Projekte übrig. Die wirklich interssanten Sachen sind oft closed-source, da kann man aber versuchen, zumindest das Prinzip rauszufinden.
udok schrieb: > Keiner schaut sich jeden Quellcode an, oder liest jedes Buch. > Da muss dir schon wirklich sehr langweilig sein. Ich lese Bücher hauptsächlich auf Empfehlung von Freunden und Bekannten. Manche auch, weil ich eine interessante Rezension darüber gelesen habe. Progbit schrieb: > Zu dem TE und seiner Erwartungshaltung sage ich lieber nichts Meine Erwartungshaltung ist, dass etwa 5% aller Forenbeiträge hilfreich sind. Bis jetzt ist die Quote ganz gut erfüllt.
udok schrieb: > Sondern man hat ein Problem oder Interesse, und dann schaut > man, was es da schon gibt, und wie es andere gemacht haben. Genau so sieht die Praxis aus. Und ich selbst kann mich ehrlich gesagt nicht daran erinnern, dass mir Freunde oder Arbeitskollegen jemals Fachaufsätze oder gar -Bücher mal eben so zum schmökern genannt haben. Da schmöker ich doch grundsätzlich in anderen Genres. Anders ist das natürlich, wenn man an einem Problem arbeitet...das muß ja auch nicht nur Software sein! Da kann der Kollege schon mal - auch überraschend - den "absoluten Knaller" aus dem Ärmel ziehen. Gruß Rainer
Jörg W. schrieb: > Sieht interessant aus, wenngleich ich nicht so der Freund davon wäre, > sowas wie das printf-Fahrrad nochmal zu erfinden. Naja, die newlib ist nicht gerade dafür bekannt besonders schlank zu sein (jedenfalls nicht im "Mikrocontroller-Maßstab") und die newlib-nano ist bekannterweise nicht threadsafe/reentrant. Darüber hinaus brauchen beide für printf malloc und das printf von LVGL eben nicht. Unter all diesen Gesichtspunkten finde ich es durchaus in Ordnung das "printf-Fahrrad nochmal zu erfinden" ;) ChibiOS kommt (vermutlich aus genau den gleichen Gründen) ebenfalls mit einem eigenen printf daher. Die printf-Implementierung von LVGL stammt übrigens ursprünglich von hier: https://github.com/mpaland/printf/ Das erfüllt für sich eigentlich schon das Kriterium "lesenswerter Code" oder zumindest sollte es dem ein oder anderen von Nutzen sein.
Christopher J. schrieb: > Darüber hinaus brauchen beide für printf malloc Sicher, dass die Implementierung selbst das braucht? Ich hätte jetzt drauf getippt, dass es nur fürs Buffering nötig ist, aber das kann man mit setvbuf() beeinflussen (inklusive eines eigenen Puffers). Ich müsste mir die Details allerdings ansehen. Allerdings gehöre ich ohnehin zu den Leuten, die keine malloc-Phobie haben. Schließlich war ein eigenes malloc() mein Einstieg in die avr-libc-Entwicklung …
Lieber Walter... Vorschlag zur Güte. Du suchst dir ein "richtig gutes" ( und nach Horst Evers muß es ein richtig, richtig gutes Problem sein) und das programmierst du dann und dann stellst du das ins Netz und wartest du...z.B., ob der Code nur scheisse ist....oder ob er wirklich richtig scheisse ist oder ob es irgendjemand überhaupt interessiert...und dann verbesserst du deinen Code... verstanden?! Gruß Rainer
Jörg W. schrieb: >> Darüber hinaus brauchen beide für printf malloc > > Sicher, dass die Implementierung selbst das braucht? Habe mal geschaut. Es wird für drei Fälle gebraucht: * as*printf - logisch, denn das verlangt ja explizit malloc * _WANT_IO_C99_FORMATS feature aktiv (%a / %A formate) * _MB_CAPABLE feature und "zu langes" Ergebnis für %S oder *ll[dxiou] Wenn jemand partout kein malloc haben möchte, kann er ein malloc selbst liefern, das immer NULL zurück gibt (bzw. ein _sbrk), dann gibt's halt einen Fehler, wenn so eine Bedingung triggert. Back to topic: der Code für stdio in der newlib ist BSD code, und man kann ihn zumindest lesen. ;-) Anders als GNU arbeitet BSD mit 8er TABs und entsprechend einem 8er Einrückungsniveau. Damit das alles nicht zu breit wird (der originale Code passte auf ein 80x24 Terminal), muss man also schon ganz gut strukturieren.
Rainer V. schrieb: > Vorschlag zur Güte [...] und dann stellst du das ins Netz und wartest > du...z.B., ob der Code nur scheisse ist Die Logik dahinter verstehe ich nicht. Meine Frage: "Wo finde ich guten Quelltext?" und die Antwort ist "Programmier etwas und lass andere prüfen, ob das gut ist!" Damit wird unterstellt, dass es keinen guten lesenswerten Quelltext gibt, wenn ich den erst schreiben muss. 1 Dollar schrieb: > Du kannst auch fehlerhaften Code nehmen und daraus lernen. Schlechten Quelltext habe ich schon viel gesehen. Das Wissen, wie ein schlechter Quelltext aussieht hilft sehr wenig dabei, guten zu machen. Am gleichen Problem ist meine Karriere als bildender Künstler schon im stolzen Alter von 6 Jahren gescheitert. Der Hinweis, dass meine Bilder schlecht aussehen, ist völlig wertlos, wenn man keine guten Bilder zu Gesicht bekommt (und vielleicht noch den Hinweis, warum sie gut sind, aber das wäre hier zuviel verlangt). Tatsächlich habe ich gute Bilder mit Wachsmalstiften erst viele, viele Jahre später zum ersten Mal gesehen. Aber da war ich schon fast mit dem Studium fertig und eine Kehrtwende zur Kunst kam nicht mehr in Frage. Jörg W. schrieb: > der Code für stdio in der newlib ist BSD code, und man > kann ihn zumindest lesen. ;-) Das ist für printf()-ähnliche Funktionen schon eine Leistung. Danke, schaue ich mir mal an! Zur Erinnerung das Thread-Thema: "Welchen Quelltext (in C), den ihr nicht selbst geschrieben habt, findet ihr absolut lesenswert? Beispiele zu µC und GUI interessieren mich besonders."
:
Bearbeitet durch User
Walter T. schrieb: > Zur Erinnerung das Thread-Thema: > "Welchen Quelltext (in C), den ihr nicht selbst geschrieben habt, findet > ihr absolut lesenswert? Beispiele zu µC und GUI interessieren mich > besonders." Meinst du nicht du wurdest über eine Woche lang genug bespaßt? Eine Zeit in der du praktisch alle Vorschläge abgelehnt hast weil dir nichts gut genug ist, denn du kannst und weißt eigentlich schon alles.
Hannes J. schrieb: > Meinst du nicht du wurdest über eine Woche lang genug bespaßt? Ich habe 5 echte Vorschläge auf der Liste. (Dazu auf der Haben-Seite noch ein paar kurze Off-Topic-Diskussionen über free(), Sprungtabellen bei switch-case, ein paar Idiome, die auch nicht uninteressant sind.) Hannes J. schrieb: > Eine Zeit > in der du praktisch alle Vorschläge abgelehnt Von den echten 5 Vorschlägen waren drei oder vier gut. Das ist nicht gerade "alles abgelehnt". Mein weiter vorn abgeschätzer Wirkungsgrad von 5% wird also diesmal nicht ganz erreicht. Da muss man also nach dem Prinzip "Masse statt Klasse" arbeiten. Zur Erinnerung das Thread-Thema: "Welchen Quelltext (in C), den ihr nicht selbst geschrieben habt, findet ihr absolut lesenswert? Beispiele zu µC und GUI interessieren mich besonders."
:
Bearbeitet durch User
Beitrag #6808710 wurde von einem Moderator gelöscht.
Walter T. schrieb: > Mein weiter vorn abgeschätzer Wirkungsgrad von 5% wird also diesmal > nicht ganz erreicht. Naja, viel mehr hätte ich bei einer so allgemeinen Frage jetzt auch nicht wirklich erwartet. GUI auf Controller ist sowieso eher ein Randgebiet. Wenn ich heutzutage eine GUI da benutzen möchte, würde ich zu irgendwas Fertigem greifen wie Qt und dann eine entsprechend leistungsfähige Hardware benutzen, typischerweise dann auch eher mit einem OS drunter. Damit unterscheidet sich die Software dann nur hinsichtlich der maximalen Bildgröße von PCs.
Walter T. schrieb: > Schlechten Quelltext habe ich schon viel gesehen. Das Wissen, wie ein > schlechter Quelltext aussieht hilft sehr wenig dabei, guten zu machen. Mann, wir sind hier nicht bei der Maus!!! Ich habe es schon mal gesagt und ich wiederhole es jetzt noch mal ausdrücklich. Deine Frage ist Blödsinn!!! Glaube es oder nicht...du hast ja genug Leute hier, die dich mit "gutem Code" quasi zuscheissen. Damit mußt du leben. Ist für mich auch kein Wunder...nur du wunderst dich... Rainer
Jörg W. schrieb: > Naja, viel mehr hätte ich bei einer so allgemeinen Frage jetzt auch > nicht wirklich erwartet. Ich auch nicht. Es gibt eben Vorgänge, wo man über 5% Wirkungsgrad froh ist. Jörg W. schrieb: > GUI auf Controller ist sowieso eher ein Randgebiet. Erstaunlich, oder? Immerhin hat so ein BluePill eine Rechenleistung, die die meines C128D mit Desktop-GUI übertrifft. (Es hat keine Grafik-Chips und weniger RAM, deswegen relativiert sich das etwas. Aber für eine begrenzte Mensch-Maschine-Schnittstelle reicht es locker.) Und der komfortabel große Speicher hat ja auch irgendeinen Verwendungszweck. Die wenigsten werden wohl Systeme mit 10000 Zustandsvariablen haben. Jörg W. schrieb: > Wenn ich heutzutage > eine GUI da benutzen möchte, würde ich zu irgendwas Fertigem greifen wie > Qt und dann eine entsprechend leistungsfähige Hardware benutzen Für ein kommerzielles Produkt, bei dem Entwicklungszeit eine Rolle spielt, sicher.
:
Bearbeitet durch User
Walter T. schrieb: > Jörg W. schrieb: >> GUI auf Controller ist sowieso eher ein Randgebiet. > > Erstaunlich, oder? Immerhin hat so ein BluePill eine Rechenleistung, die > die meines C128D mit Desktop-GUI übertrifft. Ja, aber die Entwicklung einer brauchbaren GUI-Bibliothek schluckt Mannjahre. Da greift man lieber auf was Fertiges zurück. >> Wenn ich heutzutage >> eine GUI da benutzen möchte, würde ich zu irgendwas Fertigem greifen wie >> Qt und dann eine entsprechend leistungsfähige Hardware benutzen > > Für ein kommerzielles Produkt, bei dem Entwicklungszeit eine Rolle > spielt, sicher. Kommerziell lohnt es sich u.U., Aufwand in so eine Entwicklung zu stecken, um mit minimaler Hardware auszukommen – wenn man erwarten kann, dass hinreichend große Stückzahlen verkaufbar sind, sodass sich der hohe Entwicklungsaufwand lohnt. Privat ist der Preisunterschied zwischen so eine MCU-Demoboard und einem kleinen Single-Board-Computer, auf dem ich dann Linux, NetBSD oder was auch immer laufen lassen kann, zu gering, als dass ich mir den Softwareaufwand ohne Not antun würde.
Jörg W. schrieb: > Ja, aber die Entwicklung einer brauchbaren GUI-Bibliothek schluckt > Mannjahre. Da greift man lieber auf was Fertiges zurück. Wem sagst Du das. Jörg W. schrieb: > Privat ist der Preisunterschied zwischen so eine MCU-Demoboard und einem > kleinen Single-Board-Computer, auf dem ich dann Linux, NetBSD oder was > auch immer laufen lassen kann, zu gering, als dass ich mir den > Softwareaufwand ohne Not antun würde. Privat messe ich die Qualität einer GUI hauptsächlich an der Reiz-Reaktions-Kompatibilität, und dazu gehört auch die Reaktionszeit. Bei letzterer können die GHz-Boliden selten mit dem µC mithalten. Warum auch immer. Aber in der Hinsicht bin ich wohl auch ein Sonderling.
>Mann, wir sind hier nicht bei der Maus!!! Wenn dich die Frage nicht interessiert, halt die Klappe. > Ich habe es schon mal gesagt >und ich wiederhole es jetzt noch mal ausdrücklich. Deine Frage ist >Blödsinn!!! Glaube es oder nicht...du hast ja genug Leute hier, die dich >mit "gutem Code" quasi zuscheissen. Damit mußt du leben. Ist für mich >auch kein Wunder...nur du wunderst dich... >Rainer Die Frage von Walter ist klar formuliert und durchaus berechtigt. Man kann ja auch jemand nach einem guten Buch fragen wenn man Leute auf der gleichen Wellenlänge hat, bekommt man auch gute Tipps. Was wieder einmal typisch für dieses Forum ist, dass ständig über irgendwas nur nicht über die Sache diskutiert wird. Anscheinend ist es für die meisten hier nicht möglich, auf den Punkt zu kommen oder überhaupt auch nur die Fragestellung zu begreifen. Um mal diesen dummen Kreis zu unterbrechen, werfe ich hier mal das STM32Duino Repository in die Waagschale: https://github.com/stm32duino/Arduino_Core_STM32 Das interessante hier ist die Verzeichnisstrukur. Einerseits sind die vielen unterstützen Prozessoren im Variantenverzeichnis organisiert und andererseits gibt es das Library Verzeichnis. Sehr gut ist, dass es bei den Libraries immer ein Verzeichnis "examples" gibt. Diese sind kurz gehalten, so dass man sie leicht verstehen kann und schnell auch kompilieren und ausprobieren kann. Das ist ganz im Gegensatz zu den Beispielen wie sie bei vielen anderen Controllersystemen gemacht sind. Dort sind sie meistens völlig überladen und kaum kompilierbar. Hier mal als Beispiel die EEPROM Library: https://github.com/stm32duino/Arduino_Core_STM32/tree/master/libraries/EEPROM/examples
Walter T. schrieb: > 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. Nur noch mal als Erinnerung...steht ja noch viel mehr da... Markus schrieb: > Um mal diesen dummen Kreis zu unterbrechen, werfe ich hier mal das > STM32Duino Repository in die Waagschale: und? Ich sehe den TO im Kreis hüpfen und jubilieren...und jetzt? Rainer
udok schrieb: > Was ist guter Sourcecode (persöhnliche Rangliste)? Ich habe vor ein paar Jahren mit dem kommerziellen Reliance (Flash Disc Filesystem) ein Projekt machen dürfen. Ich war von dem Source wirklich sehr beeindruckt und erfüllte meines Erachtens die erwähnte Rangliste ausnahmslos. Unten der Link zu der OS Variante. https://github.com/datalightinc/reliance-edge
:
Bearbeitet durch User
900ss D. schrieb: > Ich war von dem Source wirklich sehr beeindruckt und erfüllte meines > Erachtens die erwähnte Rangliste ausnahmslos. Ich würde mich stark an der "ungarischen" Notation stören. Aber strukturiert scheint er gut zu sein.
Jörg W. schrieb: > 900ss D. schrieb: >> Ich war von dem Source wirklich sehr beeindruckt und erfüllte meines >> Erachtens die erwähnte Rangliste ausnahmslos. > > Ich würde mich stark an der "ungarischen" Notation stören. Aber > strukturiert scheint er gut zu sein. Die ungarische Notation ist "Geschmackssache" finde ich. Ich kann soetwas gut filtern im Kopf. Ich sehe das nicht ;) Auch Quellcode von anderen Leuten habe ich selten Probleme mit solange es nicht wirklich Kraut&Rüben ist. Auch sinnvoll eingesetzte "goto" sind ok, finde ich. Die Struktur ist eine der besten mit, die ich je gesehen habe. Auch die Kommentierung des Source ist wirklich beispielhaft gut. Und auch sehr lesbar geschrieben. Und funktionieren tut das Zeug auch noch ;) Diese OS Variante hab ich allerdings nie ausprobiert. Aber nur diese kann ich hier verlinken.
:
Bearbeitet durch User
900ss D. schrieb: > Die ungarische Notation ist "Geschmackssache" finde ich. Ich kann > soetwas gut filtern im Kopf. Ich nicht. Als ich zum ersten Mal Variablen wie lpFoo gesehen habe, habe ich mich gefragt, was sie damit wohl drucken wollen. ;-) ("lp" = traditionelle Abkürzung für "line printer")
Jörg W. schrieb: > Jörg W. schrieb: > >>> Darüber hinaus brauchen beide für printf malloc >> >> Sicher, dass die Implementierung selbst das braucht? > > Habe mal geschaut. Es wird für drei Fälle gebraucht: > > as*printf - logisch, denn das verlangt ja explizit malloc > _WANT_IO_C99_FORMATS feature aktiv (%a / %A formate) > _MB_CAPABLE feature und "zu langes" Ergebnis für %S oder *ll[dxiou] Ich muss gestehen, dass ich in dem Source-Code der newlib da nicht richtig durchgestiegen bin, obwohl ich mir das auch angeschaut hatte. Eine malloc-Phobie habe ich jedenfalls nicht aber trotzdem Danke, dass du das klargestellt hast. Jörg W. schrieb: > 900ss D. schrieb: > >> Ich war von dem Source wirklich sehr beeindruckt und erfüllte meines >> Erachtens die erwähnte Rangliste ausnahmslos. > > Ich würde mich stark an der "ungarischen" Notation stören. Aber > strukturiert scheint er gut zu sein. Ich bin auch absolut kein Freund der ungarischen Notation aber gerade wenn es um eine Bibliothek geht, würde ich (als Anwender) eine gute Strukturierung jederzeit als wichtiger einstufen, als das der Quelltext nach meinem "Geschmack" geschrieben ist, denn Geschmack ist ja bekanntlich Geschmackssache. In diesem Sinne gibt es jedoch ein paar Fälle mit denen ich so überhaupt nicht klar komme, etwa wenn jemand Tabs und Spaces mischt und dann je nach Lust und Laune mal ein Tab und mal zwei Leerzeichen in die Tastatur hämmert, wobei dann je nach Editoreinstellung der Quelltext nur noch wie "zerrissene Hosen" aussieht. Es heißt ja immer "das Auge isst mit" und in diesem Sinne wäre das dann so etwas wie Wiener Schnitzel mit Spaghetti. Es funktioniert zwar irgendwie aber schön ist es nicht. PS: Mir ist gerade noch so ein OS-Projekt eingefallen, was ich durchaus sehr schätze, was aber ebenfalls in ungarischer Notation verfasst ist und zwar Freemodbus: https://github.com/cwalter-at/freemodbus Auch da würde ich sagen Struktur und Dokumentation top, ungarische Notation, naja...
:
Bearbeitet durch User
Christopher J. schrieb: > Ich bin auch absolut kein Freund der ungarischen Notation aber gerade > wenn es um eine Bibliothek geht, würde ich (als Anwender) eine gute > Strukturierung jederzeit als wichtiger einstufen, als das der Quelltext > nach meinem "Geschmack" geschrieben ist, denn Geschmack ist ja > bekanntlich Geschmackssache. Dafür würde mich das auch nicht weiter interessieren. Allerdings ging es ja im Thread vor allem um lesenswerten Sourcecode, und da finde ich zwar die Strukturierung gut, aber die ungarische Notation gruselig. > In diesem Sinne gibt es jedoch ein paar Fälle mit denen ich so überhaupt > nicht klar komme, etwa wenn jemand Tabs und Spaces mischt Ich mag das auch nicht, aber ich habe Opensource-Projekte, bei denen so viele Leute im Code herum geschrieben haben, dass genau das bei einigen Dateien der Fall ist. Ich selbst lass mir im Editor die TABs hervorheben, um das zu vermeiden (und trailing whitespace wird knallrot dargestellt), aber ansonsten bemühe ich mich da in erster Linie um Konsistenz: hat die aktuelle Datei TABs, benutze ich sie auch, ist sie mit Spaces eingerückt, mache ich es auch so. Per Rundumschlag das alles zu ändern, ist anders Mist, weil es spätere Sourcecode-Vergleiche über Versionen extrem erschwert. Diese Lektion hatte FreeBSD mal in seiner Anfangszeit gelernt … Insofern kann ich Walter AVRDUDE als "wie man es nicht machen sollte, es aber trotzdem passiert" (nicht) empfehlen. :-)
:
Bearbeitet durch Moderator
Beitrag #6809414 wurde von einem Moderator gelöscht.
Christopher J. schrieb: > Auch da würde ich sagen Struktur und Dokumentation top, ungarische > Notation, naja... Nicht nur das, auch die Benutzung von whitespace ist arg unüblich. Normalerweise wird nach einer öffnenden oder vor einer schließenden Klammer kein Leerzeichen geschrieben. (Macht man im normalen Text ja auch nicht.)
..also ist doch wirklich Mumpitz. Vor allem auch, weil sich der TO gar nicht mehr meldet. Nun können die restlichen Beteiligten eine neue Wohngruppe aufmachen und gut is...und ob jetzt gerade auch noch eine Diskussion zur polnischen Notation sein muß, das wage ich zu bezweifeln, bringt aber Wind in die verschiedenen Fraktionen! (Diese polnische Notation hat noch niemand wirklich gemocht...und irgendwann wird das auch sicher ausgerottet sein...) Gruß Rainer
Rainer V. schrieb: > Diese polnische Notation hat noch niemand wirklich gemocht...und > irgendwann wird das auch sicher ausgerottet sein. Charles Simonyi wird sie wohl mal gemocht haben. ;-)
:
Bearbeitet durch Moderator
Rainer V. schrieb: > polnischen Notation Selbst die umgekehrte polnische Notation hat(te) einen gewissen Beliebtheitsgrad.
EAF schrieb: > Selbst die umgekehrte polnische Notation hat(te) einen gewissen > Beliebtheitsgrad. Deutlich mehr als die ungarische. ;-) Geht auch auf Mikrocontrollern: FORTH. Aber GUI-Programmierung damit habe ich noch nicht gesehen.
:
Bearbeitet durch Moderator
Der Wikipedia Artikel zur ungarischen Notation ist super: >Durch diese Doppeldeutigkeit existieren zwei Strömungen der Ungarischen >Notation, das Apps Hungarian, welches die echte Notation im Sinne Simonyis >ist, und das Systems Hungarian, welches durch die Fehlinterpretation der >Microsoftschen Betriebssystemabteilung entstanden ist. Letzteres ist für >den schlechten Ruf der Konvention verantwortlich, weil die Benennung einer >Variablen nach dem Datentyp wenig zum Verständnis des Inhalts beiträgt und >trotzdem viel Aufwand verursacht. https://de.wikipedia.org/wiki/Ungarische_Notation
Jörg W. schrieb: > Ich selbst lass mir im Editor die TABs hervorheben, um das zu vermeiden > (und trailing whitespace wird knallrot dargestellt), aber ansonsten > bemühe ich mich da in erster Linie um Konsistenz: hat die aktuelle Datei > TABs, benutze ich sie auch, ist sie mit Spaces eingerückt, mache ich es > auch so. Konsistenz ist mir persönlich auch am wichtigsten. Von daher ist das für mich auch direkt ein Qualitätsmerkmal, wenn bei OS-Software nicht nur ein Stil vorgegeben wird, sondern auch auf irgendeine Art und Weise umgesetzt wird. Ob das dann ein Perl-Script ist (Linux-Kernel), ein Shell-Script (freemodbus), clangtidy genutzt wird (PX4) oder im einfachsten Fall auch einfach nur eine .editorconfig genutzt wird ist mir dann erstmal egal. Gerade letzteres wird von jedem halbwegs brauchbaren Editor unterstützt und hat sonst keine weiteren Abhängigkeiten.
Wenn eine Variable die Temperatur angibt, dann soll sie meiner Meinung nach auch gefälligst "temperatur" heissen. Nicht fTemperatur oder so. Der konkrete Typ interessiert mich beim lesen des Quelltextes nur sekundär (wenn überhaupt) und dann kann ich bei der Definition schauen oder in einer anständigen IDE drauf zeigen um ihn angezeigt zu bekommen. Gleiches gilt für Funktionsnamen: > ftemperatur=fTemperaturToFahrenheit(fMesswert); sieht für mich ziemlich Gaga aus. Ich bevorzuge: > temperatur=toFahrenheit(messwert); Sprechende Namen: ja, aber nicht mit unnötigem Schnickschnack garniert. Selbst mit strengem Regelwerk hat jeder Programmierer mehr oder weniger seinen eigenen Stil. Da kann man fordern so viel man will, ein einheitliches Bild kriegt man nur hin, wenn man ganz alleine arbeitet. Professionelle Programmierer müssen sich mit unterschiedlichen Stilen arrangieren, weil Menschen, Projekte und Regeln im Laufe der Zeit wechseln. Wer alte Programme pflegt, weis das. Je länger ich im Business bin, umso stärker wächst bei mir die Erkenntnis, dass schriftliche Regelwerke zum Programmierstil weitgehend sinnlos sind. Man kann sie in Form eines Buches gerne mal als Empfehlung lesen, aber macht daraus bitte kein Unternehmens-Gesetz. Es genügt schon, mit den Kollegen offen über Bedürfnisse zu reden, damit man die ganz schlimmen Fauxpässe gemeinsam vermeidet. Wer viel mehr verlangt, ist in meinen Augen kein guter Programmierer.
Jörg W. schrieb: >> Diese polnische Notation hat noch niemand wirklich gemocht...und >> irgendwann wird das auch sicher ausgerottet sein. > > Charles Simonyi wird sie wohl mal gemocht haben. ;-) Ich mag sie auch :-) Vorallem wenn sie konsequent durchgezogen ist, ist sie eine Wohltat im Vergleich zu so manchem modernen C++ Code, in dem es vor "auto" nur so wimmelt, und man gar keine Change hat, auf den Datentyp draufzukommen. Da ist perl ja oft noch lesbarer. Ein gutes Beispiel ist die Microsoft Foundation Class MFC, und der Source Code von Windows NT.
udok schrieb: > eine Wohltat im Vergleich zu so manchem modernen C++ Code, in dem es > vor "auto" nur so wimmelt Dieses Schlüsselwort habe ich noch nie verwendet. Ist wohl neu, muss ich mir mal angucken. Allerdings wurde gerade in Java das scheinbar ähnliche "var" eingeführt welches ich manchmal gerne nutze. Beispiel:
1 | Map<String,Map<String,User>> groups = db.getGroupedUsers(); // keys= groupName, userName |
2 | for (var group : groups.entrySet()) |
3 | {
|
4 | for (var user : group.entrySet()) |
5 | {
|
6 | ...
|
7 | }
|
8 | }
|
Hier ist offensichtlich, welchen Datentyp "var" hat. Die vollstänsig ausgeschriebene Version bringt mir keinen Erkenntnisgewinn, ist aber wegen der langen Zeilen schwerer lesabr:
1 | Map<String,Map<String,User>> groups = db.getGroupedUsers(); // keys= groupName, userName |
2 | for (Map.Entry<String,Map<String,User>> group : groups.entrySet()) |
3 | {
|
4 | for (Map.Entry<String,User> user : group.entrySet()) |
5 | {
|
6 | ...
|
7 | }
|
8 | }
|
Übertrieben fände ich jedoch dies:
1 | var groups = db.getGroupedUsers(); // keys= groupName, userName |
2 | for (var group : groups.entrySet()) |
3 | {
|
4 | for (var user : group.entrySet()) |
5 | {
|
6 | ...
|
7 | }
|
8 | }
|
Weil man überhaupt nicht mehr sehen kann, mit welchen Datentypen man eigentlich hantiert. Bei einfachen Typen braucht man das auch nicht, aber hier schon, finde ich. Meintest du das?
Danke für die brauchbaren Beiträge auf der zweiten Hälfte der zweiten Seite! Ich habe jetzt erst einmal genug zu lesen. Mit Arduino kam ein Vorschlag aus völlig unerwarteter Ecke, aber klar: Die haben noch mehr als andere das Problem, eine erdrückende Vielfalt an Varianten handhaben zu müssen. In Teile der newlib mal einen Blick zu werfen, kann auch aus anderen Gründen schon nicht schaden.
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.