J. S. schrieb: > klar, aber wo steht da drin das es alles Resourcenverschwendung ist oder > Objekte dynmaisch erzeugt werden müssen? Vielleicht ist es Ressourcenverschwendung etwas zu lernen was man nicht unbedingt braucht.
ja, wenn man mit der Einstellung 'das will ich nicht' rangeht, dann ist es vergeudete Zeit. Deshalb schrieb ich 'wer sich dafür interessiert'.
:
Bearbeitet durch User
J. S. schrieb: > das es alles Resourcenverschwendung ist 1: Woher sich die ableitet hab ich erklärt. 2: Ständige Wiederholungen langweilen. MaWin schrieb: > Du bist doch hier derjenige, der überzeugen will, dass OOP schlecht ist. 3:Sie hat ihr Einsatzgebiet, ersetzt aber längst nicht alles. Davon war die Rede. Bist Du persönlich gekränkt? MaWin schrieb: > Kannst du es noch einmal zusammenfassen? GOTO 2
J. S. schrieb: > ja, wenn man mit der Einstellung 'das will ich nicht' rangeht, > dann ist es vergeudete Zeit. > Deshalb schrieb ich 'wer sich dafür interessiert'. Du scheinst nur davon auszugehen daß das Studium der Fachkektüre automatisch zu Begeisterung und lebenslanger Anwendung führt. Das ist ein Irrtum.
Ralf schrieb: > 1: Woher sich die ableitet hab ich erklärt. nein, nur behauptet das OOP nur für Programme und Daten im 100 MB Bereich gebraucht würde. Das ist keine Erklärung.
> Die Zero-Cost-Abstraktionen schon einmal per Definition nicht. > Die brauchen keinerlei Laufzeit und keinerlei Speicher. Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits erst mal Berechnungen usw durchführen (müssen), sind es keine Zero-Cost-Abstraktionen.
J. S. schrieb: > nein, nur behauptet das OOP nur für Programme und Daten im 100 MB > Bereich gebraucht würde. Das ist keine Erklärung. Nun beginnt wohl die Phase sich beliebiges aus den Fingern zu saugen? Belassen wir es dabei!
Ralf schrieb: > Ich sehe die Welt wie sie ist Das ist nicht wahr! Das ist gelogen. Deine Sinne und Wahrnehmung sind begrenzt. Unbekanntes wird mit Fantasiegebilden ausgefüllt. Nein, was du sieht ist nur eine Projektion. Du selber projizierst dein inneres Bild, der Welt, auf die Welt. Und dieses siehst du, mehr nicht. Aufmerksame Zeitgenossen bemerken wenn sich Sprünge/Fehlerstellen in der Projektion bilden und korrigieren ihr Weltbild.
MCUA schrieb: > Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits > erst mal Berechnungen usw durchführen (müssen), sind es keine > Zero-Cost-Abstraktionen. Schöner kann man seine Unkenntnis kaum noch zur Schau stellen. Ralf schrieb: >> Kannst du es noch einmal zusammenfassen? > > GOTO 2 Kommt also nichts mehr. Auch gut. > Bist Du persönlich gekränkt? Dass ich mich von einem anonymen Nichtsblicker aus dem Internet persönlich kränken lasse. Soweit wirds noch kommen. Ganz bestimmt.
MCUA schrieb: > Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits > erst mal Berechnungen usw durchführen (müssen), sind es keine > Zero-Cost-Abstraktionen. Lass gut sein. Am Beispiel EAF ist abzulesen wozu zuviel OOP Gegenwind führt. Das wird dann allzu irrational.
Es wird sicher seine vielen unterschiedlichen Gründe haben dass man für diese oder jene Anwendung jeweils das eine oder andere bevorzugt. Immerhin ist sowohl das eine als auch das andere weit verbreitet. Über die Grenze zu diskutieren wann das eine oder andere sinnvoller ist, ergibt keinen Sinn, da sie sicher fließend mit reichlich Überschneidungen verläuft.
Stefan F. schrieb: > Uwe D. schrieb: >> ‚Go‘ wurde nicht für talentfreie OOP Einsteiger entworfen. > > Dann lies das mal: > > "The key point here is our programmers are Googlers, they’re not > researchers. They’re typically, fairly young, fresh out of school, > probably learned Java, maybe learned C or C++, probably learned Python. > ….. Stefan, den Aspekt will ich nicht klein reden. Also ich habe >20 Jahre im direkten MS-Umfeld verbracht und das, was nicht mit den alten Zöpfen gut ging, war alles rund um Azure und dessen Ökosystem… Und Google bzw. AWS haben das gleiche Thema. Das haut in die selbe Kerbe wie RUST (da gibt es hier ja auch so einen schönen Thread) & Co.
>> Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits >> erst mal Berechnungen usw durchführen (müssen), sind es keine >> Zero-Cost-Abstraktionen. > Schöner kann man seine Unkenntnis kaum noch zur Schau stellen. Was du nicht alles sagst. Du schreibst statt kompaktem Code zig Klassen, die mit Codierung alle erst mal durchlaufen werden müssen, und laberst dann was von 'Zero-Cost-Abstraktionen'. Träum weiter.
> Kannst du es noch einmal zusammenfassen?
Kannst du lesen?
Die Anzahl 'seiner' Klassen, die in WIRKLICHKEIT 'Zero-Cost-Abstraktionen' sind: Keine!
Der Empfindlichkeit mancher Leute merkt man klar an, wieviel Wunschdenken, wieviel Dogmatik, wieviel Ideologie hier im Spiel ist. Ihr schönes Denk-Spielzeug darf keinesfalls kritisiert werden, dann sind sie gleich auf 180. Da dreht sich offensichtlich das ganze Selbstverständnis drum. Ich programmiere ja auch aus Leidenschaft, aber so mag ich nicht enden! Schönen Sonntag noch!
Ralf schrieb: > Der Empfindlichkeit mancher Leute merkt man klar an, wieviel > Wunschdenken, wieviel Dogmatik, wieviel Ideologie hier im Spiel ist. Ja, und zwar auf beiden Seiten. > Ich programmiere ja auch aus Leidenschaft, aber so mag ich nicht enden! Ich fürchte, dafür ist es zu spät. > Schönen Sonntag noch! Ebenso.
Ralf schrieb: > Der Empfindlichkeit mancher Leute merkt man klar an, wieviel > Wunschdenken, wieviel Dogmatik, wieviel Ideologie hier im Spiel ist. Ihr > schönes Denk-Spielzeug darf keinesfalls kritisiert werden, dann sind sie > gleich auf 180. Da dreht sich offensichtlich das ganze Selbstverständnis > drum. Dieser Aussage stimme ich durchaus zu 110 % zu.
Ralf schrieb: > Leidenschaft Ist das, was Leiden schafft. Du armes kleines Föschlein.... Musst ganz alleine ... im Brunnen ... dein Leiden erschaffen. Keiner möchte zu dir, in deinen Brunnen. Vielleicht ist das stickige düstere Loch ja doch nicht das gelbe vom Ei. Tipp: Es gibt eine Außenwelt. Du musst nicht alleine in dem Loch verrotten. MCUA schrieb: > In ASM gibt es mehr Datentypen, als man zählen kann! Jau! Und nachts ist es kälter als draußen.
Beitrag #7281948 wurde von einem Moderator gelöscht.
Beitrag #7281949 wurde von einem Moderator gelöscht.
Gerhard O. schrieb: > Irgendwie finde ich die häufigen pauschale Abwertungen im Forum > unangebracht, weil sie zu subjektiv sind und meist professionellen > Standards und Gewohnheiten zugrunde liegen. Man darf nicht immer von > sich auf andere schließen. Ein Neuling wird das ohnehin nicht so > empfinden können. Hallo mein lieber Gerhard! Warum machen das manche hier? Ganz klar für mich. Die mussten sich früher durch quälen und nun kommt jemand daher und entwickelt wirklich was richtig Tolles und ohne wirklich genau jedes Bit zu kennen. Er muss sich nur seiner Kreativität widmen, was vermutlich diese anderen Typen gar nicht haben. Die können nur ihre Bits schieben. Natürlich nicht alle. Was ist so schlimm daran, wenn das mit "KlickiBunt" klappt? Wir hätten wohl immer noch keine Fernbedienung, Klimaanlagen und Standheizungen oder SmartHome, wenn wir nicht nach dem Bequemen streben würden. Leider haben andere früher mit meinen Ideen Geld, sogar viel Geld verdient. Wären die Sachen so einfach gewesen, also "KlickiBunt", dann hätte ich diese Projekte alle selbst entwickelt und wäre heute womöglich richtig reich. Ich glaube diese Typen haben nur Angst, weil es das Einzige ist, was sie wirklich gut können. Habe in meinem Beruf als Fluggerätemechaniker mal einen Typen kennen gelernt, der kannte alle Bestellnummern und Schlüsselweiten aus dem Kopf. Nur wenn es um komplexe Problemlösungen ging, da war er draußen. Der ritt auch immer drauf rum, dass ich nicht immer sofort wusste welchen Schlüssel ich brauche und dass ich mir die Nummern nicht merkte. Ich war insgesamt ein Jahr in dem Unternehmen. Schon nach kurzer Zeit holte der Chef mich immer bei Problemen dabei und der Typ stand in zweiter Reihe, mit großen Augen. Diese Typen haben nur eine Sache richtig drauf, aber auch nur, weil sie das ewig machen. Keiner weiß mehr was die im Anfang für schlechte Anfänger waren.
Beitrag #7283617 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283617:
> Das hatte der Gerhard doch gar nicht für schlimm befunden.
Gerhard war auch gar nicht gemeint.
Ich habe das nur aufgegriffen.
Habe ich übrigens auch geschrieben, dass das nicht alle sind.
Aber hier gibt es zwei, drei Leute, die meinen man müsste erstmal
Assembler und dann C und überhaupt ganz viel Elektronik lernen und erst
dann, nach ganz langer Zeit, dürfen sie einen Mikrocontroller
programmieren.
Die wollen im Grunde nicht, dass das jeder kann. Maximal Gleichgesinnte
dürfen dazu stoßen.
Aber zum Glück haben die nichts zu sagen und können nur mit ihren
abwertenden Bemerkungen kommen.
Beitrag #7283639 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283639: > Nun kommt ein Anfänger mit Arduino vorbei und baut > womöglich das gleiche Projekt mit viel einfacheren > Mitteln. Welche dann C++ sind.
Beitrag #7283646 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283646:
> Assembler
Nein!
Die von dir beschriebene "schnelle+einfache Projektentwicklung" beruht
bei Arduino auf C++.
Sowas wäre in ASM nicht erreichbar.
EAF schrieb: > Ralf schrieb: >> Nun kommt ein Anfänger mit Arduino vorbei und baut >> womöglich das gleiche Projekt mit viel einfacheren >> Mitteln > Welche dann C++ sind. Naja, viele Anfänger halten es für eine Arduino Sprache. Und sie benutzen die vorhandenen Objekte, C++ programmieren würde ich das noch nicht nennen. Aber man ist auf einer guten Spur und kann alles nutzen und erstellen was die Sprache hergibt.
Aber das scheint in der Tat ein Punkt zu sein, das den selbstherrlichen Königen da ein Zacken aus der Krone bricht.
MaWin schrieb: > Pardon, du musst bei led.on() irgendwo nachschauen, was gemacht wird und > bei PORTC |= (1<<7) nicht? Das allegemeine aneinander-vorbei-Heulen ist ja noch nicht zuende - oder? Also, mal zum gefälligen Bedenken: 1. led.on() setzt das Definieren und Kreieren eines Objektes voraus. Wenn man das in der Ebene der Algorithmen macht, dann schafft man damit einen eigentlich unerwünschten Hardwarebezug. Alternative: Sowas in eine separaten Quelle für die Lowlevel-Dinge tun. Allerdings ist dann die Frage, wieso man dort dafür erst noch ein Objekt schaffen will, denn mit einer ganz simplen Funktion led_on() ist das viel einfacher erledigt. Kein Definieren, Kreieren und Destruieren eines Objekts, keine VMT, nix außer der nackten Funktionalität des Ausschaltens. 2. Das Unterbringen von sowas wie PORTC |= (1<<7) in der Ebene der Algorithmen kann je nach Anzahl der Verwendungen Platz oder Zeit sparen, ist vergleichbar mit inline. Aber es schafft auch einen derben Hardwarebezug und macht jegliches Portieren schwer. Sowas käme bei ganz kleinen und/oder langsamen Plattformen in Frage. Leserlich wird es, wenn man es durch einen passenden Kommentar ergänzt - was ich für guten Stil halte. So, wärend es für PORTC |= (1<<7) durchaus Gefilde gibt, wo sowas in Ordnung ist, gibt es für led.on() eigentlich keinen sinnvollen Grund. Falls es sich nicht um eine LED oder sonstige Lampe etc. handelt, sondern um einen Button auf dem Grafikdisplay, dann sieht das völlig anders aus. Der ist dann nämlich ein Objekt und hat Zustände, die optisch signalisiert werden können. Hier hätten wir also den Unterschied zwischen Hardware und Software mal wieder vor Augen. Viel wichtiger ist allerdings der Verlauf dieses Threads: Hier zeigt sich deutlich, weswegen genau das Thema des Threads, also das Verwenden von eigentlich zu großen/schnellen Plattformen passiert: Anstatt eine einfache und zugleich saubere Lösung einer Aufgabe zu wählen, wird zu immer aufgedunseneren Methoden gegriffen, bloß um es im Quelltext so sparsam wie möglich stehen zu haben. Was dadurch eigentlich an Folgen verursacht wird, ist den Leuten egal. W.S.
Beitrag #7283664 wurde von einem Moderator gelöscht.
W.S. schrieb: > 1. led.on() setzt das Definieren und Kreieren eines Objektes voraus. und das ist gut so. Im Konstruktor kann der angegebene Pin als Ausgang konfiguriert werden. Das gehört ja zusammen und damit Kapitel 1 'Kappselung' abgehakt. Beim prozeduralen Ansatz muss vorher der Ausgang separat konfiguriert werden. Das ist ein typischer Anfängerfehler in Arduino, das wird oft vergessen. Ja, hier ist Arduino inkonsequent und prozedural statt OOP. Aber es war enie Entscheidung der Arduino Macher vor X Jahren, ist so.
Frank O. schrieb: > Habe ich übrigens auch geschrieben, dass das nicht alle sind. > Aber hier gibt es zwei, drei Leute, die meinen man müsste erstmal > Assembler und dann C und überhaupt ganz viel Elektronik lernen und erst > dann, nach ganz langer Zeit, dürfen sie einen Mikrocontroller > programmieren. > Die wollen im Grunde nicht, dass das jeder kann. Maximal Gleichgesinnte > dürfen dazu stoßen. > Aber zum Glück haben die nichts zu sagen und können nur mit ihren > abwertenden Bemerkungen kommen. Also ich behaupte mal, wer irgendwelches Wissen oder Fähigkeiten abwertet ist doof. Zu behaupten man brauche kein Wissen über ASM, oder Elektronik, hat doch eigentlich das gleiche Niveau wie wenn man behauptet man bräuchte kein OOP. Jedes Nichtwissen schränkt immer ein, genauso wie wenn man irgendwelche Fähigkeiten nicht besitzt. Ich kann das nicht also ist es doof. Kindergarten.
Ralf schrieb im Beitrag #7283664: > Daß weiß jeder Kenner der Materie. ASM kennt keine Datentypen ASM warnt nicht usw. Diese klaren Hints, Warnungen helfen deutlich den C und C++ Arbeiten viel schneller fertig zu werden. Jeder Handwerker weiß, dass er mit gutem Werkzeug schneller zurande kommt. Ralf schrieb im Beitrag #7283664: > Das mag darauf beruhen, Es mag nicht, sondern es beruht darauf! Modularität, Wiederverwendbarkeit und Portabilität! > Einmal schreiben überall verwenden Wieviel µC werden von Arduino unterstützt, mehr oder weniger direkt? Wohl ALLE, für die es einen Gcc mit C++ gibt. Wieviel µC unterstützt dein Assembler? Eine Familie! Keinerlei Portabilität mit anderen µC Familien. Null. Ja, ich weiß, DU in deinem AVR ASM Brunnen brauchst das alles nicht. Aber verallgemeinern, lässt sich das nicht. Dein Horizont ist eben dein Horizont. Mehr nicht.
Beitrag #7283688 wurde von einem Moderator gelöscht.
DANIEL D. schrieb: > Ich kann das nicht also ist es doof. Kindergarten. Ja, so wirds wohl meist sein! Die ASM Priester sind an C/C++ gescheitert. Die OOP Ablehner an C++/OOP Das ist ja auch noch OK.... Auf allen Ebenen kann man was bringen! Ein guter ASM Programmierer ist mir alle male lieber, als ein Schaumschläger, der mir meine Lieblingssprache kaputtquatschen will, dem man bei jedem Wort auch noch anmerkt, dass er Null Ahnung davon hat.
Ralf schrieb im Beitrag #7283688: > DANIEL D. schrieb: >> Jedes Nichtwissen schränkt immer ein > > Das ist nur richtig im Rahmen Deiner Feststellung zuvor: > DANIEL D. schrieb: >> Vielleicht ist es Ressourcenverschwendung etwas zu lernen was man nicht >> unbedingt braucht Das hat aber eher was damit zu tun dass man als Mensch normal gewisse Beschränkungen hat. Und gewisse Dinge sehr zeitaufwendig sind. Also muss man halt schauen was man will. Es ist nun mal so dass ich keine zehn Programmiersprachen beherrsche, und dann noch zehn Instrumente spielen kann, und dazu noch acht verschiedene Sprachen spreche. Und natürlich in 20 verschiedenen Sportarten Profi bin. Die eigene Unfähigkeit setzt einem halt gewisse Grenzen.
DANIEL D. schrieb: > Das hat aber eher was damit zu tun dass man als Mensch normal gewisse > Beschränkungen hat. Und gewisse Dinge sehr zeitaufwendig sind. Also muss > man halt schauen was man will. Das verstehe und akzeptiere ich, nur im direktem Vergleich von C und C++ erkenne ich die Vorteile bei letzterem. Und ich habe gut 20 Jahre wie am Fließband programmiert. Ein Kollege und ich hatten auch mal den Versuch unternommen C++ bzw. OOP zu vermitteln. Das war auch erfolglos, es fehlte aber auch der Druck das verstehen und anwenden zu müssen. Und es war lange lange vor der Arduino Zeit. > Die eigene Unfähigkeit setzt einem halt gewisse Grenzen. So eine Resignation ist auch kein guter Startpunkt, das muss man schon wertfrei angehen und versuchen zu verstehen was OOP versucht anders zu machen. Interessant ist noch das ein Arduino User auch ohne C++ Kenntnisse Objekte benutzen kann. Wie ein bekannter User hier im Forum es Punkt Menus in der IDE nennt. Dann hat eine Variable eben .irgendeine_Funktion(). Und irgendwie ist es einleuchtend das es Serial.print() und Serial.println() usw gibt.
Beitrag #7283711 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283711: > EAF schrieb: >> ASM kennt keine Datentypen > > Das ist auch sehr gut so. > Bürokratie, die ich sofort entsorgen würde. > Die Gedanken sind frei so wie die Anzahl verwendeter Datenbytes. Du möchtest die Sinnhaftigkeit von Datentypen und strenger(?) Typisierung negieren? Dein Ernst? evtl. die letzten 60 Jahre, in deinem Brunnenfroschdasein, verschlafen? Herrlich absurd, wenn da nur nicht diese Priester Attitüden wären
Beitrag #7283732 wurde von einem Moderator gelöscht.
Beitrag #7283735 wurde von einem Moderator gelöscht.
Bei Arduino geht es um Einfachheit für den Programmierer. Einfachheit ist Trumpf. Die TTB (Time To Blink, die Zeit der ersten Inbetriebnahme der IDE und dem anschließen des Mikrocontrollers, bis er blinkt) ist bei Arduino unschlagbar und dürfte so bei ca. 5 Minuten liegen. Das bietet keine andere IDE. Die Verfügbaren Anleitungen im Internet sind unendlich. Auf einem ESP32 kann man mit dem Arduino Framework Anwendungen mit WiFi erzeugen, die mit einem anderen System erst nach Jahren gemacht werden könnten. Wenn es interessiert, kann auch mal die Geschichte zu BASIC nachlesen. Das würde erst auch als einfaches Tool für Wirtschaftsingenieure entwickelt, um ihnen das Programmieren beizubringen. Es war nicht als ernsthafte Programmiersprache gedacht. Da alles andere zu der Zeit aber extrem kompliziert war und nur von Experten programmiert werden konnte, hatte es eine unglaubliche Verbreitung erreicht, auch wenn es heute längst durch besser Alternativen ersetzt wurde.
J. S. schrieb: > Hmm, mein Compiler wirft einen Fehler weil er PORTC nicht kennt. > > Es geht doch dabei um Abstraktion. Und die DigitalOut oder was auch > immer Klasse wird als Komponente getestet damit ich mich darauf > verlassen kann. Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den du verwenden willst, nicht gibt. Bei deiner Abstraktion weißt du erst, dass es nicht funktionieren kannst, wenn du versuchst am Mikrocontroller verzweifelt eine LED an den nicht vorhanden PORTC anzuschließen... ;) Es hat halt alles seine Vor- und Nachteile. ;)
M. K. schrieb: > Es hat halt alles seine Vor- und Nachteile. ;) Wie bereits gesagt: Man kann machen Abstraktionen gut; man kann machen Abstraktionen schlecht. Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles verkacken kann.
MaWin O. schrieb: > Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles > verkacken kann. Wenn man betrachtet, wie erfolgreich Arduino ist, würde ich nicht davon sprechen, dass man da alles verkackt hat ;)
M. K. schrieb > Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den > du verwenden willst, nicht gibt. Das mache ich zum Beispiel in meinen eigenen Bibliotheken:
1 | portpin_set_output(PORT_C,4); |
wird bei einem Controller ohne Port C (z.B. bei allen Renesas-Typen, bei denen sind die Ports numerisch 0..14) einen Fehler werfen, weil PORT_C dort nirgendwo definiert ist. Den Unterstrich habe ich übrigens deswegen eingeführt, um Kollisionen mit Register-Namen zu vermeiden. Ansonsten muss ich aus eigener Erfahrung sagen, dass jemand, der früher die meisten Z80-Befehle auswendig konnte und im Kopf assembliert hat und zwischenzeitlich über ASM nach C gekommen ist, sich ungemein schwer mit OOP tut. Jörg
Beitrag #7283924 wurde von einem Moderator gelöscht.
M. K. schrieb: > Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den > du verwenden willst, nicht gibt. Bei deiner Abstraktion weißt du erst, > dass es nicht funktionieren kannst, wenn du versuchst am Mikrocontroller > verzweifelt eine LED an den nicht vorhanden PORTC anzuschließen... ;) Die Abstraktionsschicht muss ja auch kompiliert werden. Und da würden schon die falschen Headerfiles zu Fehlern führen.
Joerg W. schrieb: > Das mache ich zum Beispiel in meinen eigenen > Bibliotheken:portpin_set_output(PORT_C,4); > wird bei einem Controller ohne Port C (z.B. bei allen Renesas-Typen, bei > denen sind die Ports numerisch 0..14) einen Fehler werfen, weil PORT_C > dort nirgendwo definiert ist. Den Unterstrich habe ich übrigens > deswegen eingeführt, um Kollisionen mit Register-Namen zu vermeiden. Und was passiert, wenn Du
1 | portpin_set_output(PORTC, 4); |
oder
1 | portpin_set_output(PORT_C, 8); |
schreibst? Oder ein beliebter Fehler in der AVR-Gemeinde:
1 | SPCR0 = SPI2X0; |
> Ansonsten muss ich aus eigener Erfahrung sagen, dass jemand, der früher > die meisten Z80-Befehle auswendig konnte und im Kopf assembliert hat und > zwischenzeitlich über ASM nach C gekommen ist, sich ungemein schwer mit > OOP tut. Damit bist Du sicher nicht allein. Wer zuviel ASM oder C eingesaugt hat, tut sich schwer mit Abstraktionen.
M. K. schrieb: > MaWin O. schrieb: >> Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles >> verkacken kann. > > Wenn man betrachtet, wie erfolgreich Arduino ist, würde ich nicht davon > sprechen, dass man da alles verkackt hat ;) Ja doch. Das kann man sehr wohl. Nur weil etwas verbreitet ist, wird es nicht automatisch gut. Manchmal sogar ganz im Gegenteil. Starke Verbreitung verhindert Änderungen. J. S. schrieb: > Die Abstraktionsschicht muss ja auch kompiliert werden. Und da würden > schon die falschen Headerfiles zu Fehlern führen. Wenn man sich nicht auf diese antiquierte Sprache C beschränken würde, wäre noch viel mehr (Typ-)Sicherheit möglich. HAL können typsicher, speichersicher, threadsicher, interruptsicher, idiotensicher und zero-cost sein. Siehe embedded-hal für Rust.
Joerg W. schrieb: > portpin_set_output(PORT_C,4); und wenn der portpin nicht auf Ausgang eingestellt ist? Werden die Argumente auf Gültigkeit überprüft? Das wird dann üblicherweise dem Performancegott geopfert. In der bösen HAL sind dafür überall ASSERT Makros drin. Vermutlich werden diese von vielen als überflüssiger Code angesehen, aber da wird nur Code erzeugt wenn vorher ein Symbol definiert wird um diese Überprüfungen zu aktivieren.
J. S. schrieb: > und wenn der portpin nicht auf Ausgang eingestellt ist? Werden die > Argumente auf Gültigkeit überprüft? Das wird dann üblicherweise dem > Performancegott geopfert. Oder halt zero-cost vom Typsystem geprüft. Kannst du machen gut. Kannst du machen kacke. Man hat die Wahl. Arduino hat eine Wahl getroffen.
J. S. schrieb: > Das wird dann üblicherweise dem > Performancegott geopfert. Vieles kann man zur Compilezeit machen (in C++).
Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit OOP auch gut kontrollieren?
DANIEL D. schrieb: > Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür > Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit > OOP auch gut kontrollieren? Selbstverständlich. Zero-cost bedeutet zero-cost. Keine zusätzliche Laufzeit. Kein zusätzlicher RAM-Bedarf. Kein zusätzlicher Flash-Bedarf. Null. Man kann natürlich in OOP Code so schreiben, dass mehr Ressourcen verwendet werden. Vor allem, wenn man Features verwendet, die ohne OOP nicht "einfach so" zur Verfügung stehen. z.B. vtables. Aber diese Kosten hat man genau so auch, wenn man vtables in C implementiert. Ein Programmcode implementiert in statischer OOP hat keinen zusätzlichen Overhead verglichen mit dem gleichen Code in rein klassischen C. Und ich bin übrigens kein Freund von komplexer OOP mit tiefer (Mehrfach-)Vererbung und pipapo. Aber eine vernünftige Objektbasierung hilft enorm beim Strukturieren des Programms.
DANIEL D. schrieb: > Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür > Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit > OOP auch gut kontrollieren? Der Begriff OOP beinhaltet (typischerweise) die Konzepte: - Kapselung via Klassen - Inklusionspolymorphie durch Vererbung - Laufzeitpolymorphie durch Inklusionspolymorphie - weitere Polymorphiearten: ad-hoc Polymorphie, parametrische Polymorphie Bei µC kommen viel mehr die Konzepte Kapselung und parametrische und ad-hoc-Polymorphie zum Einsatz als die Laufzeitpolymorphie.
MaWin O. schrieb: > Und ich bin übrigens kein Freund von komplexer OOP mit tiefer > (Mehrfach-)Vererbung und pipapo. Das ist heute niemand mehr im Gegensatz zu den ganz frühen Anfangszeiten der OOP. Heute gilt: Komposition vor Vererbung.
J. S. schrieb: > In der bösen HAL sind dafür überall ASSERT Makros drin. Vermutlich > werden diese von vielen als überflüssiger Code angesehen, aber da wird > nur Code erzeugt wenn vorher ein Symbol definiert wird um diese > Überprüfungen zu aktivieren. Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn NDEBUG gesetzt wird.
in HAL gibt es in vielen Funktionen:
1 | /* Check the parameters */ |
2 | assert_param(IS_GPIO_ALL_INSTANCE(GPIOx)); |
3 | assert_param(IS_GPIO_PIN(GPIO_Init->Pin)); |
4 | assert_param(IS_GPIO_MODE(GPIO_Init->Mode)); |
und assert_param macht:
1 | /* Exported macro ------------------------------------------------------------*/ |
2 | #ifdef USE_FULL_ASSERT |
3 | /** |
4 | * @brief The assert_param macro is used for functions parameters check. |
5 | * @param expr If expr is false, it calls assert_failed function |
6 | * which reports the name of the source file and the source |
7 | * line number of the call that failed. |
8 | * If expr is true, it returns no value. |
9 | * @retval None |
10 | */ |
11 | #define assert_param(expr) ((expr) ? (void)0U : assert_failed((uint8_t *)__FILE__, __LINE__)) |
12 | /* Exported functions ------------------------------------------------------- */ |
13 | void assert_failed(uint8_t *file, uint32_t line); |
14 | #else |
15 | #define assert_param(expr) ((void)0U) |
16 | #endif /* USE_FULL_ASSERT */ |
Das hat also nichts mit NDEBUG zu tun sondern USE_FULL_ASSERT.
:
Bearbeitet durch User
J. S. schrieb: > in HAL gibt es in vielen Funktionen Nicht alle HAL sind STM-HAL ;-)
:
Bearbeitet durch User
ich dachte mit 'böser' HAL war klar welche gemeint ist...
J. S. schrieb: > ich dachte mit 'böser' HAL war klar welche gemeint ist... Zumindest enthält sie ja schon mal Laufzeitzusicherungen ;-) Wobei ein µC Programmierer ja möglichst Compile-Zeit-Zusicherungen (bzw. einfach Compiler-Fehlermeldungen wegen z.B. nicht erfüllter Typ-Anforderungen) haben möchte stattdessen. Und das kann eine in C geschriebene HAL eben nur sehr begrenzt im Gegensatz zu C++.
Wilhelm M. schrieb: > Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn > NDEBUG gesetzt wird. Nicht die Zusicherungen, sondern deren Überprüfung.
Rolf M. schrieb: > Wilhelm M. schrieb: >> Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn >> NDEBUG gesetzt wird. > > Nicht die Zusicherungen, sondern deren Überprüfung. Nö, das assert-Macro evaluiert in dem Fall zu einem leeren String. Damit entfernt der Präprozessor als nicht-interaktiver Editor die Zusicherung.
MaWin O. schrieb: > Nur weil etwas verbreitet ist, wird es nicht automatisch gut. Hätte man bei Arduino alles verkackt hätte sich dieses System ganz sicher nie verbreitet. Wer bestanden hat hat noch lange keine Note 1 oder 2, da hast du recht. Aber der hat auch ganz sicher keine Note 5 oder 6. ;)
Wilhelm M. schrieb: > Nö, das assert-Macro evaluiert in dem Fall zu einem leeren String. Ja, richtig. > Damit entfernt der Präprozessor als nicht-interaktiver Editor die > Zusicherung. Die Zusicherung ist das, was du bzw. dein Code durch Hinschreiben des assert abgibt. Je nach Einstellung überprüft der Compiler diese oder nicht. Aber auch wenn er das nicht überprüft, bleibt es trotzdem das, was zugesichert wurde.
Wenn ich böser HAL lese, muss ich sofort an 2001 denken...
*portpin_set_output(PORTC, 4);*
1 | rc/test_01_blink.c: In function 'main': |
2 | src/test_01_blink.c:15:2: error: incompatible type for argument 1 of 'portpin_set_output' |
3 | portpin_set_output(PORTC,4); |
4 | ^ |
5 | In file included from ./inc/board.h:2:0, |
6 | from src/test_01_blink.c:1: |
7 | /usr/local/toolchain/unilib/avr/include/unilib.h:7346:6: note: expected 'unsigned char' but argument is of type 'volatile union PORTC_T' |
8 | void portpin_set_output(unsigned char port,unsigned char pin); |
9 | ^ |
10 | make: *** [Makefile:69: build/src/test_01_blink.o] Fehler 1 |
Bei anderen Controllern mit PORT C (z.B. HCS08) gibt es kein PORTC Register. *portpin_set_output(PORT_C, 8);* Würde entweder PTC8 auf Output setzen oder PTC0, wenn Port C nur 8 Bits breit ist. Da die Pin-Nummer ja eine Variable ist, kann die ja im Programm parktisch den ganzen Bereich von 0 bis 255 einnehmen:
1 | for(i=0;i<8;i++) portpin_set_output(PORT_C, i); |
ist ja auch gültig, daher habe ich mich für Modulo entschieden, das lässt sich leicht und schnell mit einem AND realisieren. Jörg
DANIEL D. schrieb: > Jedes Nichtwissen schränkt immer ein, genauso wie wenn man irgendwelche > Fähigkeiten nicht besitzt. Im wesentlichen bin ich bei dir. Dennoch hast du, so glaube ich, das nicht verstanden, was ich damit sagen wollte. Jeder der halbwegs etwas lernen will, wird später sowieso mehr über Elektronik wissen, mehr über Programmiersprachen und diese benutzen. Aber im Anfang ist man doch froh, wenn das so irgendwie klappt, das was man machen wollte. Da will jemand etwas bauen, lesen wir doch täglich, und kann sich die Problematik noch nicht im Geringsten vorstellen. Ich hatte schon einige Jahre mit Elektronik zu tun, dachte ich. Als ich hier anfing zu lernen und das Kapitel "Kondensator" im TS gelesen hatte, wusste ich, dass ich nicht einmal annähernd die Bauteile kannte. Aber gerade bei Arduino ist es doch so, dass fundamentales Wissen erstmal nicht nötig ist. Vergleichen wir das mit dem Autofahren. Du musst einen Führerschein besitzen. Das ist dein Grundwissen. Viele wollen nur Auto fahren, einige machen noch dne Ölwechsel selbst und andere können die ganze Elektronik, haben Diagnosegeräte und zerlegen, wenn nötig, die ganze Karre. Also lasst die, die nur fahren wollen, doch auch nur fahren. Von den Typen, die hier immer so auf die Sahne hauen, möchte ich mal sehen, ob die auch einen ganzen Motor zerlegen und wieder zusammensetzen können, sodass er auch noch läuft. Und der, der das kann, hat der schon ein Dach verlattet und gedeckt, Wände gemauert ... Ich bin mir sicher, jeder der mit Arduino anfängt etwas zu machen, hat auf anderen Gebieten auch gute Kenntnisse.
Frank O. schrieb: > Aber gerade bei Arduino ist es doch so, dass fundamentales Wissen > erstmal nicht nötig ist. > Vergleichen wir das mit dem Autofahren. Du musst einen Führerschein > besitzen. Das ist dein Grundwissen. Viele wollen nur Auto fahren, einige > machen noch dne Ölwechsel selbst und andere können die ganze Elektronik, > haben Diagnosegeräte und zerlegen, wenn nötig, die ganze Karre. > Also lasst die, die nur fahren wollen, doch auch nur fahren. > Von den Typen, die hier immer so auf die Sahne hauen, möchte ich mal > sehen, ob die auch einen ganzen Motor zerlegen und wieder zusammensetzen > können, sodass er auch noch läuft. > Und der, der das kann, hat der schon ein Dach verlattet und gedeckt, > Wände gemauert ... > Ich bin mir sicher, jeder der mit Arduino anfängt etwas zu machen, hat > auf anderen Gebieten auch gute Kenntnisse. Ist halt auch die Frage wo man herkommt, ein Mensch welcher berufsmäßig PC Software programmiert und das Hobby Microcontroller entdeckt, wird sicher anders an die Sache herangehen als z.b ein Mensch welcher Elektronik beherrscht, und sich auch das Programmieren von Microcontrollern aneigenen will. Natürlich wäre es geil wenn man Programmieren kann ASM, C und C++, in der Lage ist Schaltungen und Platinenlayouts zu erstellen, und am besten noch analoge Elektronik und bis zum selbstentwickelten Schaltenetzteil und was weiß ich beherrscht. Aber realistisch betrachtet braucht man Unmengen an Wissen und Erfahrung um davon jeweils nur einzelne Dinge wirklich gut zu beherrschen. Es reicht nicht ein Buch gelesen zu haben. Seien wir ehrlich Dinge machen Spaß wenn man sie gut kann. Und es gibt ja auch noch andere Dinge im Leben neben der Elektronik. Also muss man halt eine Auswahl treffen, und wenn man schon seine Microcontroller programmieren kann, wird man vermutlich viel eher etwas anderes lernen, vielleicht das Bearbeiten von Metall oder was auch immer für die eigenen Projekte und Wünsche vorteilhaft ist, anstelle einer Programmiersprache welche schwer zu erlernen ist, und im Vergleich zu anderen Dingen einen geringeren mehrwert bietet. Das meine ich mit Investieren. Ich habe einen 3D Drucker hier rumstehen welcher seit Jahren nicht fertig wird. Aber ich bin handwerklich begabt, also baue ich mir einfach den Kram direkt aus Holz und Metall wenn es sein muss. Meistens denke ich mir das es halt viel schöner als Plastik zu verwenden, und schon fehlt die Motivation sich die Arbeit zu machen den 3D Drucker fertigzustellen. Dabei bin ich in der Lage ein CAD (skatchup) ausreichend zu bedienen. Ja wäre ja wirklich geil wenn man alles könnte aber man ist halt beschränkt.
Frank O. schrieb: > Aber gerade bei Arduino ist es doch so, dass fundamentales Wissen > erstmal nicht nötig ist. > Vergleichen wir das mit dem Autofahren. So weit brauchst du gar nicht ab schweifen.Denke nur an Bauklötze, Lego, Fischer Technik und Metallbaukästen. Wie viele echte Baumeister haben wohl damit angefangen? Ich vermute: fast alle. > Also lasst die, die nur fahren wollen, doch auch nur fahren. Sehr gut, gefällt mir.
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.