lässt sich für einen Software-Entwurf eines Microcontrollers sagen, dass man hardwarenah, objektorientiert programmiert hat?
Bild schrieb: > lässt sich für einen Software-Entwurf eines Microcontrollers sagen, dass > man hardwarenah, objektorientiert programmiert hat? Na klar, wenn es denn tatsächlich so ist... Sagen kann man es auch dann, wenn es nicht so ist. Nur muss man dann halt damit rechnen, dass diese Aussage widerlegt wird...
Wenn Du z.B. für Deine Ports ne Klasse geschrieben hast, die die ganze Bitpfrimelei kapselt, hast Du objektorientiert hardwarenah programmiert. Dasselbe gilt natürlich auch für die Benutzeroberfläche. Wenn Du das Ganze dann noch mittels UML entwickelt hast, bist du der King und ich bin stolz auf Dich. ;-) mfg
Bild schrieb: > lässt sich für einen Software-Entwurf eines Microcontrollers > sagen, dass man hardwarenah, objektorientiert programmiert hat? Definiere Hardware-Nähe! Je abstrakter das Ganze, je mehr Software-Schichten dazwischen desto Hardware-ferner.
Lies Dir eine Dir genehme und anerkannte Definition oder Beschreibung von oop durch und setze es entsprechend um. Ich habe schon objektorientierte SW in Assembler gesehen und Spaghetti-Code in C++. OOP ist keine Frage der Sprache, sondern der Umsetzung.
Bild schrieb: > lässt sich für einen Software-Entwurf eines Microcontrollers > sagen, dass man hardwarenah, objektorientiert programmiert hat? Selten. Das klassische objektorientierte Programm besteht aus Konstruktoren (und Destruktoren) in Klassen, also dynamischen Speicheranforderungen, und quasi alle robust funktionierenden hardwarenahen Programme vermeiden Speicheranforderungen (malloc) wie der Teufel das Weihwasser. Es kommt halt doof, wenn deine Armbanduhr sagt: Memory full (excessive fragmentation). Man kann aber auch bei objektorientierter Programmierung nur statische Objekte anlegen, und sich auch sonst Mühe geben, daß kein Maschinenbefehl mehr erzeugt wird, als für die Lösung der Aufgabe nötig. Damit sind aber 99% der objektorientierten Prorammierer heillos überfordert.
A. S. schrieb: > objektorientierte SW in Assembler Sollte damit die verwendete Programmiersprache und nicht das Dekompilat gemeint sein wüsste ich gerne wie man das anstellt. Soll man ein Unterprogramm mit zugehörigen Daten etwa als Objekt bezeichnen?
M.C. schrieb: > Soll man ein Unterprogramm mit zugehörigen Daten etwa als Objekt > bezeichnen? Das wäre arg kurzgegriffen. Eher Strukturen mit jeweils einem Set von Funktionen und Nachrichten. Inclusive Überladung der Funktionen. Dass man dabei z.b. den thispointer mit übergeben muss (explizit oder implizit) ist vielleicht lästig, aber OK.
Einfach so sagen kann man das nicht, die hardwarenahe Programmierung müsste man schon irgendwie begründen können. Gegenseitig ausschließen tun sich die Betrachtungsweisen nicht. Vom Sprachansatz macht es aber keinen Sinn. Was man aber z.B. zu Haskell sagen kann, das ist, es ist eigentlich nur wieder (mal) ein neues Lisp. Der Mangel an Standardisierung - und das Problem hat eben auch die Assembler/Hexcode - Welt: -> lieber C Vom technischen her schaut man eher auf den Übersetzer, Peephole-Optimierung, Datentypenpräferenzen, Alignements, MC-Typ u.ä. ( https://en.wikipedia.org/wiki/Peephole_optimization ) (z.B.)
Moin, Bild schrieb: > lässt sich für einen Software-Entwurf eines Microcontrollers > sagen, dass > man hardwarenah, objektorientiert programmiert hat? Aber selbstverstaendlich kann man das sagen. Bei mir haette es einen aehnlichen Effekt, wie wenn jemand sagen wuerde, er haette seinen µC-Softwareentwurf maximal disruptiv mit Blockchaintechnologie aus der Cloud programmiert. Gruss WK
Bild schrieb: > lässt sich für einen Software-Entwurf eines Microcontrollers sagen, dass > man hardwarenah, objektorientiert programmiert hat? Die Frage ist vollkommen sinnlos. Allgemein kann man sowas schon mal gar nicht sagen, man muß immer eine konkrete Software betrachen. Dazu kommt noch, daß schon bei "objektorientiert" kein Konsens darüber besteht, was man denn alles dazu zählen möchte und was nicht. Mal ganz davon abgesehen, daß OOP ein Mittel ist und kein Zweck. Folgerichtig erlaubt z.B. C++ das Mischen von prozeduralem und OO Code. Wieviel OO muß in einem Programm sein, damit man es "objektorientiert" nennen kann? Reicht eine überladene Funktion oder eine zur class "geadelte" struct ? Bei "hardwarenah" ist es noch viel schlimmer. Was soll das denn sein? Gibt es überhaupt ein Gegenteil? Auf einem µC? Und wie sieht es aus, wenn man ein (eigenes) Abstraktionslayer verwendet, um Anwendungslogik und Hardware voneinander zu entkoppeln?
ich habe meine Antwort bekommen: jeder hat eine andere Meinung, also werde ich meine auch begründet bekommen =) Vielen Dank
A. S. schrieb: > M.C. schrieb: > Soll man ein Unterprogramm mit zugehörigen Daten etwa als Objekt > bezeichnen? > > Das wäre arg kurzgegriffen. Eher Strukturen mit jeweils einem Set von > Funktionen und Nachrichten. Inclusive Überladung der Funktionen. Dass > man dabei z.b. den thispointer mit übergeben muss (explizit oder > implizit) ist vielleicht lästig, aber OK. Warum zum Teufel sollte man das in Asm realisieren wollen! Das klingt und ruft geradezu nach Hochsprache. Axel S. schrieb: > Bei "hardwarenah" ist es noch viel schlimmer. Was soll das denn sein? Ohne irgendwelche Abstraktions-Layer. Bare Metal.
M.C. schrieb: > Ohne irgendwelche Abstraktions-Layer. > Bare Metal. Abstraktion? Ist das nicht der Hauptzweck der OOP, gleich neben der Kapselung?!?!
> Man kann aber auch bei objektorientierter Programmierung nur statische > Objekte anlegen, und sich auch sonst Mühe geben, daß kein > Maschinenbefehl mehr erzeugt wird, als für die Lösung der Aufgabe nötig. Objektorientierte Programmierung im Embedded Umfeld heisst ja vermutlich C++. Die Sprache ist mittlerweile so komplex das vermutlich nur ein kleiner Teil wirklich zu 100% versteht was man damit machen kann. Ich selbst schaetze mich z.B irgendwo bei 30-50% ein. Aber nur wenn man nahe 100% ist kann man sicher immer die Sachen vermeiden die man vermeiden sollte. > Damit sind aber 99% der objektorientierten Prorammierer heillos > überfordert. Das ist genau mein Eindruck. Also gibt es es wohl folgende Ansaetze: 1. Man nutzt Mikrocontroller die sowohl von der Rechenleistung wie auch vom Ram stark ueberdimensioniert sind. Solange man nichts baut wo es auf jedes mW ankommt ist das heute ja moeglich. Dann macht es nichts wenn die Faehigkeiten des Programmierers nur knapp ueber Arduino-Copy-Level liegt. 2. Man nutzt neue Sprachen wo man das einfacher macht damit auch Durschnittprogrammierer damit klarkommen. Will sich aber nicht so recht durchsetzen obwohl da viel Wind gemacht wird. 3. Man stellt sich der Erkenntnis das es in Firmen viel alten Code und viele alte Programmierer gibt die da nicht mitkommen und die man schlecht (sowohl Leute wie Code) mit 50 in Rente schicken kann und gibt auf. Olaf
Arduino Fanboy D. schrieb: > M.C. schrieb: > Ohne irgendwelche Abstraktions-Layer. > Bare Metal. > > Abstraktion? > Ist das nicht der Hauptzweck der OOP, gleich neben der Kapselung?!?! Deshalb hat OOP ihre eigenen Maßstäbe für "Hardware-Nähe", weiter entfernt davon, der Hardware wirklich nah zu sein :)
M.C. schrieb: > ihre eigenen Maßstäbe Verstehe ich nicht ... Sehe keine Messlatte! (macht aber auch nix)
Arduino Fanboy D. schrieb: > Sehe keine Messlatte! Messlatte ist ganz grob das Abstraktions-Niveau. Und ganz praktisch: Setz den Ausgang im zugehörigen Hardware-Register und über die entsprechende Methode Deiner Klasse XY - dann vergleiche die Ausführungszeit!
M.C. schrieb: > Setz den Ausgang im zugehörigen Hardware-Register > und über die entsprechende Methode Deiner Klasse XY - dann vergleiche > die Ausführungszeit! Das ist u.A. mein täglich Brot. Und kann dir sagen mit OOP,Templates und den Compileroptimierungen gerade die Registermanipulation zu ASM Statements zusammenfällt, die auch ein ASM Programmierer kaum knapper hin bekommt. Deine Messlatte versagt.
M.C. schrieb: > Warum zum Teufel sollte man das in Asm realisieren wollen! > Das klingt und ruft geradezu nach Hochsprache. ?? Ich habe weder geschrieben, dass man sowas in Assembler machen sollte, noch dass es in den letzten 20 Jahren sinnvoll war. Es gab aber Mal eine Zeit, wo Assembler für Performance wirklich wichtig war. Und wenn man Assembler programmiert, sollte es trotzdem kein Spaghetticode werden.
A. S. schrieb: > Ich habe weder geschrieben, dass man sowas in Assembler machen sollte, > noch dass es in den letzten 20 Jahren sinnvoll war. A. S. schrieb: > Ich habe schon objektorientierte SW in Assembler gesehen Arduino Fanboy D. schrieb: > Deine Messlatte versagt Zu den Asm-Statements muss man aber auch erst mal gelangen. Das bei OOP meist ein weiter Weg , vor allem wegen MaWin schrieb: > daß kein > Maschinenbefehl mehr erzeugt wird, als für die Lösung der Aufgabe nötig. > Damit sind aber 99% der objektorientierten Prorammierer heillos > überfordert. Ich glaube aber daß das restliche Prozent Deine Behauptung beweisen kann und OOP kein prinzipielles Hindernis darstellt.
M.C. schrieb: > Ich glaube aber daß das restliche Prozent Deine Behauptung beweisen kann > und OOP kein prinzipielles Hindernis darstellt. Schön! Damit kann man den Beweis als geführt ansehen. OOP ist kein Hindernis. Die Hemmschuhe stecken im Kopf und sind damit ein Problem jedes einzelnen. Kein prinzipielles Problem.
Arduino Fanboy D. schrieb: > Die Hemmschuhe stecken im Kopf und sind damit ein Problem jedes > einzelnen. Tja so einfach ist es dann doch nicht. Diese Hemmschuhe lösen sich schneller wenn das Kopf-richtige (=bessere) Werkzeug verwendet wird. Da sind diverse OOP Sprachen mit ihrer Komplexität leider eher Last als Lust. Zuweilen wird gerne vergessen, daß das Werkzeug dem Menschen angepasst sein sollte und nicht umgekehrt. Der Anspruch von OOP, einen intuitiveren Zugang zur effizienten Lösung von Programmier-Aufgabenstellungen zu bieten ist doch bei sehr vielen Köpfen gescheitert.
M.C. schrieb: > Der Anspruch von OOP, einen > intuitiveren Zugang zur effizienten Lösung von > Programmier-Aufgabenstellungen zu bieten ist doch bei sehr vielen Köpfen > gescheitert. Den Anspruch, dass eine Herztransplantation Leben rettet, können auch nur sehr wenige Menschen erfüllen. Selbst unter den Ärzten. Heißt das jetzt, dass das Werkzeug ungeeignet ist? Ist der Apfel sauer, weil er so hoch hängt? Merke: Manche Annahmen sind so dermaßen falsch, dass noch nicht mal das Gegenteil richtig ist.
Arduino Fanboy D. schrieb: > Heißt das jetzt, dass das Werkzeug ungeeignet ist? Ist der Apfel sauer, > weil er so hoch hängt? Aus der Frage spricht eine Menge Unverständnis. Du scheinst nicht begreifen zu wollen daß "Eignung" in diesem Fall keine objektive Eigenschaft ist sondern ziemlich subjektiv auch von demjenigen abhängt der ein solches Denk -Werkzeug verwendet. Wenn sich nun tatsächlich 99% der OOP Verwender heillos überfordert sehen damit effizient zu programmieren- für und gegen was spricht das denn Deiner Meinung nach? Arduino Fanboy D. schrieb: > Und kann dir sagen mit OOP,Templates und den Compileroptimierungen Gut daß es dazu noch viele einfachere Alternativen gibt.
M.C. schrieb: > Wenn sich nun > tatsächlich 99% der OOP Verwender heillos überfordert sehen damit > effizient zu programmieren Und ich möchte mir nicht ausmalen, was das für die Code-Qualität bedeutet. Vermutlich hängen auch viele Medien- prominente Software-Fehler damit zusammen.
M.C. schrieb: > für und gegen was spricht das denn Deiner > Meinung nach? Ich weiß nicht, ob deine Fragestellungen und Behauptungen zielführend sind. Denn ich kenne dein Ziel nicht. Ich könnte dich jetzt fragen: Welch Ziele stehen hinter deiner OOP/C++ Diffamierungsaktion? Was ist deine Absicht? Aber das tue ich nicht. Zumindest erwarte ich keine Antwort. Aus meiner Sicht, gibt es verschiedenste Talente. Ein paar davon scheinen für gute Programmierer wichtig zu sein. Ich nenne es gerne das "Programmierer Gen". Dann gibts natürlich die Vorgeschichte des Einzelnen. Wer mit Assembler und/oder C anfängt, tut sich mit OO Sicht auf die Dinge recht schwer. Meine Empfehlung: Mit einer OOP Sprache beginnen. Denn der Weg aus der OOP zum Prozeduralen ist leichter, als umgekehrt. Auch sollte man das urteilen über die Qualität eines Werkzeugs/Strategie/Sichtweise denen überlassen, die sich damit auskennen und, von mir aus, täglich einsetzen. Oftmals verteufeln diejenigen die OOP am stärksten, welche am wenigsten damit am Hut haben. (was der Bauer nicht kennt, das frisst er nicht) Gibts Argumente für ASM? Klar! Gibts welche dagegen? Ebenso klar. Man kann also die Frage "Nehme ich ASM?" von den konkreten Anforderungen und persönlichen Vorlieben abhängig machen. Das gilt natürlich für alle Sprachen und alle Situationen! Man muss nur ein bisschen aufpassen, dass man die eigenen Erfahrungen und Vorlieben nicht auf andere projiziert.
Das beste OOP nützt nichts, wenn der Programmablaufplan nichts taugt. Mit schlecht strukturiertem PAP kommt selbst der 1000 mal schnellere 32Bit-Bolide ins Keuchen, wo bei gut durchdachtem PAP der 8Bitter noch Däumchen dreht. Anders gesagt, OOP kann einem in keinen Fall das Denken abnehmen. Zu überlegen, wie man ein Programm sinnvoll strukturiert, d.h. wann und wie oft eine Funktion wirklich aufgerufen werden muß und wieviel CPU-Zeit sie benötigt, interessiert das OOP nicht die Bohne. Ob man das Ergebnis einer lang dauernden Berechnung für die weitere Verarbeitung erstmal zwischenspeichern muß, kann nur der Mensch entscheiden.
Bild schrieb: > ich habe meine Antwort bekommen: jeder hat eine andere Meinung, also > werde ich meine auch begründet bekommen =) Auf jeden Fall.. für mich selbst hatte die Frage etwas von einem Kippbild (irgendein Beispiel): https://www.welt.de/kmpkt/article181612648/Optische-Illusion-Was-du-hier-als-Erstes-siehst-ist-von-deinem-Alter-abhaengig.html Aber bei Emulatoren z.B. da reicht die Begründung oft nicht aus, sondern der praktische Nutzen sollte eventuell erkennbar sein. Wenn z.B. ein Moogfilterplugin für Cubase auch tatsächlich wie ein Minimoog klingt oder anders: wie gut muss die Simulation sein, dass man wenigstens damit arbeiten kann. Das DosBox so gut/praktisch ist, hat sich in den vielen Jahren des Einsatzes gezeigt. Ein Java-Cpu-Simulator zum Lernen? Sehr schön, aber wie gut lernt es sich damit bzw. bringt das tatsächlich was, oder ist man eher bei Proof Of Concept und müsste da zumindest die Grenzen benennen, die übertreten werden.
Arduino Fanboy D. schrieb: > M.C. schrieb: > für und gegen was spricht das denn Deiner > Meinung nach? > > Ich weiß nicht, ob deine Fragestellungen und Behauptungen zielführend > sind. Nein. Du mogelst Dich um eine Antwort auf die gestellte Frage. Peter D. schrieb: > Das beste OOP nützt nichts, wenn der Programmablaufplan nichts > taugt. Das sei hier mal vorausgesetzt.
A. S. schrieb: > OOP ist keine Frage der Sprache, sondern der Umsetzung. Sehr gut, darauf sollte man immer wieder hinweisen. Denn manche Bücher über Programmiersprachen tun so, als hätten die Entwickler der jeweiligen Programmiersprache die OOP erst erfunden oder ermöglicht - was definitiv großer Quatsch ist.
M.C. schrieb: > Du mogelst Dich um eine Antwort auf die gestellte Frage. Welche Frage? Für wen das spricht? Auf jeden Fall nicht für den, dessen Gehirnwindungen mit der OOP an sich nicht klar kommen und auch nicht für den, den die Besonderheiten kleiner µC überfordern. Für Leute mit dem "Gen" ist das dann eher weniger ein Problem. M.C. schrieb: > Wenn sich nun > tatsächlich 99% der OOP Verwender heillos überfordert sehen damit > effizient zu programmieren- Oder das? Was sollen die 99% da? 99% aller OOPler haben mit µC nix am Hut! Die meisten bauen große fette Brocken. Oft portabel Entwicklungszeit und Wartungskosten Die "Effizienz" Beurteilung hat in dem 99% Umfeld andere Kriterien Das eine Prozent reicht also völlig aus.
MaWin schrieb: > Damit sind aber 99% der objektorientierten Prorammierer heillos > überfordert. Sicher? Im Arduino Umfeld ist die objektorientierte Programmierung der Normalfall. Wenn das dort schon normal ist, dann erwarte ich das auch von professionellen Programmierern.
Stefan ⛄ F. schrieb: > Sicher? Im Arduino Umfeld ist die objektorientierte Programmierung der > Normalfall. Ähem. Es gibt ein paar Objekte im Arduino API, aber nicht konsequent, IO werden über Prozeduren gesetzt. Ein Serial.print() oder SPI.write() ist einfach verständlich, heisst aber noch lange nicht das der gemeine Arduino Programmierer jetzt OO programmiert. Wenn die Objekte im meterlangen loop() möglichst noch mit Goto verwurstet werden, dann hat das nix im entferntesten mit OO Paradigmen zu tun. Das soll nicht heissen das nicht auch mit Arduino ordentlich OO programmiert werden kann, eine Anleitung zum Klassen schreiben gibt es sogar in der org Doku. Aber ob das jeder Einsteiger gleich macht... Trotzdem finde ich auch den Ansatz in Objekten zu denken wesentlich besser. Das C++ dazu eine komplexe/komplizierte Sprache ist, das ist ein anderes Kapitel.
Peter D. schrieb: > OOP kann einem in keinen Fall das Denken abnehmen. Stimmt. Erstmal das Nachdenken über die eigentliche Lösung. Aber dann noch das Nachdenken, wie man dafür das verfügbare Sprachinstrumentarium einspannt/einspannen kann und zu welchem Ergebnis das jeweils führt. Inklusive aller Folgeprobleme durch Fehler dabei. Mit mehr oder weniger erforderlicher Qualifikation. Die einfachste Lösung ist meist die Beste.
Johannes S. schrieb: > Es gibt ein paar Objekte im Arduino API, aber nicht konsequent, IO > werden über Prozeduren gesetzt. Die Core API ist die am meisten als ineffizient beschimpfte. Und diese ist fast vollständig in C geschrieben. Ein bisschen ASM. Nahezu alle Libraries sind in C++ verfasst. Sowohl die Handvoll mitgelieferten und auch die tausende externen Johannes S. schrieb: > Aber ob das jeder Einsteiger gleich macht... Nöö, offensichtlich nicht. Aber das lernen der Programmierung dauert auch etwas.... Ein paar Jahre ziehen da schon ins Land. Johannes S. schrieb: > Das C++ dazu eine komplexe/komplizierte Sprache ist, das ist ein > anderes Kapitel. Ja, die Arduino Jünger nutzen eine der vielseitigsten Sprachen. Wenn da noch ein bisschen Schaltungsentwicklung zu kommt ....
M.C. schrieb: > Die einfachste Lösung ist meist die Beste. Nö. Nicht wenn es um Erweiterbarkeit und Wiederverwendung geht, da ist Abstraktion gefragt. Die Erfordert aber eine gewisse Programmiererfahrung. Wenn eine 'einfache' Lösung erweitert wird, dann kann das schnell im Chaos enden. Klassen mit mehreren Instanzen sind da schon ein sehr gutes Mittel. Einfaches Beispiel: Oled Display. Da gibts hier schöne Libraries, aber als Singleton für ein Display. Baue sowas mal auf mehrere Displays um, das wird Chaos hoch 10. OOP: eine Klasse, mehrere Instanzen.
> ... dass man hardwarenah, objektorientiert programmiert hat?
Denke gerade an die µSupply-Firmware von David (nicht Dave): Du weißt,
dass du's übertrieben hast, wenn die Identifier durch's Name-Mangling so
lang geworden sind, dass der Linker mit nem Stack-Overflow absemmelt ;-)
MaWin schrieb: > Das klassische objektorientierte Programm besteht aus Konstruktoren (und > Destruktoren) in Klassen, also dynamischen Speicheranforderungen, Das ist keine Definition von OOP. OOP muss keinen dynamischen Speicher bedeuten. Höchstens dynamische (virtuelle) Funktionsadressen.
Mark B. schrieb: > Zeig mal ein Beispiel? Das kannst du dir selber zeigen, wenn du das OO-Konzept verstanden hast. Ist doch trivial: Funktionen/Prozeduren bekommen einfach einen zusätzlichen Parameter mit: den Zeiger auf die Daten der Instanz. Das ist im Wesentlichen schon der ganze Trick von OO (also diese Parameterübergabe durch viel Syntax-Geschwalle zu verbergen). Sie findet in der objektiven Realität aber natürlich trotzdem statt. Und kostet natürlich auch die entsprechende Rechenzeit! Der restliche Vorteil von OO besteht in ein paar primitiven (und de facto leicht zu umgehenden) Sichbarkeitsregeln. Das ist schon fast alles. Naja, Polymorphie bleibt noch. Ist im Kern nix anderes als eine instanzspezifische Liste von Zeigern auf Funktionen. Auch nur durch Syntax-Geschwalle verborgen, die Indirektion des Funktionsaufrufs muss in der objektiven Realität natürlich trotzdem erfolgen und kostet die entsprechende Rechenzeit. OO ist also im Kern ein Mechanismus, der verbirgt, was wirklich passiert. Trotzdem eine sehr nützliche Sache, wenn man auf Rechenzeit und Speicherverbrauch wenig bis keine Rücksicht mehmen muß. Für kleine µC ist allerdings die klassische OOP-Geschichte ein kompletter Schuß in den Ofen. Alles, was da eventuell nützlich ist, sind Sachen, die vollständig zur Compilezeit aufgelöst werden können. Das ist sozusagen die Rettung des OO-Ansatzes. Allerdings auch wieder erkauft mit noch viel mehr schwer durchschaubarem Syntax-Bombast...
OOP ist ein ganzer Baukasten von Konzpten zur Programmierung. Niemand ist gezwungen, alle Komponenten des Baukasten zu benutzen. Insofern ist die Diskussion, was denn jetzt genau OOP ist und was noch nicht ziemlich müßig.
c-hater schrieb: > Ist doch trivial: Funktionen/Prozeduren bekommen einfach einen > zusätzlichen Parameter mit: den Zeiger auf die Daten der Instanz. Trivial? Die Programmiersprache Assembler kennt keine Konstrukte, um von einem Objekt X/einer Datenstruktur X eine Menge von Y Instanzen anzulegen. ?
:
Bearbeitet durch User
Mark B. schrieb: > Trivial? Die Programmiersprache Assembler kennt keine Konstrukte, um von > einem Objekt X/einer Datenstruktur X eine Menge von Y Instanzen > anzulegen. ? Eine Instanz von einem Objekt ist im einfachsten Fall (ohne virtuelle Methoden) einfach nur eine Ansammlung von Daten. Wer in Assembler programmiert, weiß wie man auf Daten zugreift und wie man sie ggf. kopiert.
Peter D. schrieb: > Anders gesagt, OOP kann einem in keinen Fall das Denken abnehmen. noch anders gesagt...nichts kann einem das Denken abnehmen! Und besonders schlimm ist es halt, wenn das Denken irgendwo mittendrin und völlig ohne Sinn und Verstand einsetzt. Im Gegensatz zu vielen hier, weiß ich, dass Denken "ohne Sinn und Verstand" fast die Tagesordnung ist :-) Gruß Rainer
Stefan ⛄ F. schrieb: > Wer in Assembler programmiert, weiß wie man auf Daten zugreift und wie > man sie ggf. kopiert. Naja, aber niemand der noch ganz bei Trost ist wird wohl solche Datensätze wie Personen mit Adressen und Telefonnummern etc. in Assembler verwalten wollen. Da macht es ja mehr Spaß, sich mit einer stumpfen Säge das Bein abzuschneiden. ;-)
Mark B. schrieb: > Naja, aber niemand der noch ganz bei Trost ist wird wohl solche > Datensätze wie Personen mit Adressen und Telefonnummern etc. in > Assembler verwalten wollen. Da macht es ja mehr Spaß, sich mit einer > stumpfen Säge das Bein abzuschneiden. ;-) Du würdest das offenbar nicht tun, ich auch nicht. Aber frage mal den c-hater, der wird das anders sehen. Es kommt doch primär darauf an, mit welcher Programmiersprache man am besten vertraut ist. Wie dem auch sei, Assembler und OOP schließen sich ganz sicher nicht aus. Denn wenn das der Fall wäre, gäbe es zwangsläufig auch überhaupt keine andere Programmiersprache, die OOP könnte.
Stefan ⛄ F. schrieb: > Wie dem auch sei, Assembler und OOP schließen sich ganz sicher nicht > aus. Denn wenn das der Fall wäre, gäbe es zwangsläufig auch überhaupt > keine andere Programmiersprache, die OOP könnte. Die Entstehungsgeschichte war freilich nicht so, dass es Assembler gab und man dann in Assembler anfing, OOP Konzepte umzusetzen. Das kam erst später. Assembler-Programmierung ist in aller Regel prozedurale Programmierung. Wirklich andere, in Assembler direkt brauchbare und sinnvoll benutzbare Paradigmen kennt diese Sprache nicht. Somit finde ich es etwas fragwürdig zu sagen, dass OOP in Assembler möglich sei. Ja, irgendwie möglich ist es schon - in etwa so, als ob man ein Haus baut indem man einzelne Moleküle von Kalkstein, Ton und Sand zusammensetzt.
Mark B. schrieb: > Naja, aber niemand der noch ganz bei Trost ist wird wohl solche > Datensätze wie Personen mit Adressen und Telefonnummern etc. in > Assembler verwalten wollen. Nö, natürlich nicht. Da ist ja normalerweise auch kein Bedarf dafür, dass man extrem schnell darauf zugreifen muss. Aber: es gibt durchaus Anwendungen jenseits primitiver Adressdatenbanken. Falls dir das noch nicht aufgefallen sein sollte... Und, bei nochmaliger Überlegung: selbst so eine primitive Adressdatenbank kann u.U. zeitkritisch sein, kommt halt auf die Anwendung an...
c-hater schrieb: >> Naja, aber niemand der noch ganz bei Trost ist wird wohl solche >> Datensätze wie Personen mit Adressen und Telefonnummern etc. in >> Assembler verwalten wollen. > > Nö, natürlich nicht. Da ist ja normalerweise auch kein Bedarf dafür, > dass man extrem schnell darauf zugreifen muss. Dann frag mal bei einer Versicherung oder einer Bank nach.
MaWin schrieb: > Dann frag mal bei einer Versicherung oder einer Bank nach. Da wird die Frage von einem fetten Oracle (o.ä.) Brummer beantwortet. Würde mich wundern, wenn der mit ASM bespielt wird.
Arduino Fanboy D. schrieb: > Würde mich wundern, wenn der mit ASM bespielt wird. Die großen Datenbanken sind im Kern, da wo es auf Performance ankommt, hochoptimiert.
Mark B. schrieb: > Trivial? Die Programmiersprache Assembler kennt keine Konstrukte, um von > einem Objekt X/einer Datenstruktur X eine Menge von Y Instanzen > anzulegen. ? Natürlich nicht. Aber wenn man versteht, was bei OO wirklich passiert, kann man diese Konzepte natürlich auch in Asm nutzen. Tatsächlich ist das schon vielfach passiert, bevor es dieses OO-Paradigma überhaupt gab und entsprechende Sprachen...
MaWin schrieb: >> Nö, natürlich nicht. Da ist ja normalerweise auch kein Bedarf dafür, >> dass man extrem schnell darauf zugreifen muss. > > Dann frag mal bei einer Versicherung oder einer Bank nach. Du hättest noch bis zum Ende lesen müssen... ADS?
Der erste C++ Compiler, mit dem ich damals unter DOS lernte, erzeugte C Quelltext, der von einem C Compiler nach Assembler übersetzt wurde, der von einem Assembler in Maschinencode übersetzt wurde. Die Zwischenstufen waren alle sichtbar und hatten mir geholfen, zu verstehe, wie Objekte letztendlich technisch umgesetzt werden. Jede Methode hatte in C als ersten Aufrufparameter einen Zeiger auf eine Struktur mit den Daten des Objektes. Eigentlich ist das total logisch und in jeder Programmiersprache umsetzbar. Ein zweiter wesentlicher Teil sind bei Virtuellen Methoden die indirekten Aufrufe über Zeiger. Auch das ist das total logisch und in jeder Programmiersprache umsetzbar. Wenn man das technische Konzept hinter der Fassade verstanden hat, ist es ganz einfach :-)
c-hater schrieb: > Du hättest noch bis zum Ende lesen müssen... > > ADS? Das habe ich. Ich habe dich nur bestätigt. Beißreflex?
Stefan ⛄ F. schrieb: > Wenn man das technische Konzept hinter der Fassade verstanden hat, ist > es ganz einfach :-) Ganz genau so ist das. Die Entmystifizierung von OOP. Ich habe auch erst über den Umweg der Lektüre des Asm-Codes verstanden, was der Kram eigentlich tut. Ist zwar ca. 25 Jahre her und war in meinem Fall dekompilierter Object-Pascal-Code, aber ich kann deinen Fall vollkommen nachvollziehen. Same stuff. Was ich bedenklich finde: Wenn man "von oben" rangeht (also ohne Asm- Background), dann kann es gut passieren, dass man niemals begreift, was da TATSÄCHLICH passiert, selbst wenn man auf dem OO-Abstraktionslevel sehr wohl versteht, was da passiert. Das kann nicht gut sein, das ist meine feste Meinung.
Deswegen empfehle ich jedem Programmierer, wenigstens ein bisschen Assembler zu lernen und ab und zu mal gucken, was der C-Compiler so generiert hat. Manchmal ist das sehr hilfreich. Ich konnte so schon einige Programmierfehler in meinem C Quelltext aufklären, die ich (Blindfisch) dort einfach nicht sehen konnte. Im Assembler Code war dann aber offensichtlich, wo der Fehler liegt. Das muss man nicht gleich am Anfang lernen, aber so nach einem Jahr würde ich es doch empfehlen.
Beitrag #6228279 wurde vom Autor gelöscht.
Johannes S. schrieb: > M.C. schrieb: > Die einfachste Lösung ist meist die Beste. > > Nö. Nicht wenn es um Erweiterbarkeit und Wiederverwendung geht, da ist > Abstraktion gefragt. Natürlich schließt die einfache Lösung Erweiterbarkeit und Wiederverwendung ein wenn es denn gefordert ist. Das lässt sich allerdings auch in prozeduralen Sprachen sicherstellen. > Klassen mit mehreren Instanzen sind da schon ein sehr gutes > Mittel. Einfaches Beispiel: Oled Display. Da gibts hier schöne > Libraries, aber als Singleton für ein Display. Baue sowas mal auf > mehrere Displays um, das wird Chaos hoch 10. OOP: eine Klasse, mehrere > Instanzen. . Na wär auch abenteuerlich der breit angewandten OOP die Berechtigung für ihre sinnvollen Einsatzzwecke abzusprechen. Da gehört das Handling großer Datenstrukturen sicher dazu. Generell stellt sich aber immer die Overhead- oder Wasserkopf-Frage: Steht der Verwaltungsaufwand, steht die Komplexität der Sprachmittel (samt Folgeproblemen) immer in einem sinnvollen Verhältnis zur Aufgabenstellung bzw. der letztendlichen Lösung? Klare Antwort: Nein. Nächstes Problem Abstrahierung: Kann das Zwischenschalten immer neuer Softwareschichten die Effizenz und den Ressourcenverbrauch unangetastet lassen? Klare Antwort: Nein. Die Eignung von OOP und Abstraktion für "menschliche Hirnwindungen" war bereits angesprochen. Auch hier die klare Antwort und ganz im Gegenteil zur ursprünglichen Absicht: Nein, sie ist nicht für jeden Kopf kompatibel. Aller Lernbemühung zum Trotz kommen wenn dann nur wenige auf 100% Beherrschung. Das kann aber nur in mittelmäßiger und fehleranfälliger Software münden. Man hört oft davon! Halten wir also fest: Viele Versprechungen sind durch OOP nicht eingelöst worden. Hält sich vielleicht auch deshalb hartnäckig die Vielfalt prozeduraler Sprachen? Bis hin zu Assembler! Und das 2020 :)
> Die Eignung von OOP und Abstraktion für "menschliche Hirnwindungen" war > bereits angesprochen. Auch hier die klare Antwort und ganz im Gegenteil > zur ursprünglichen Absicht: Nein, sie ist nicht für jeden Kopf > kompatibel. Das wuerde ich noch nicht mal sagen. Allerdings ist der Aufwand erheblich. So erheblich das sich vielleicht mancher der damit nicht jeden Tag 8h zutun hat fragt ob es sich lohnt. Und dann gibt es noch ein weiteres Problem. Die deutsche Fachliteratur gefaellt sich darin bewusst und uebertrieben mit Elfenbeinturm-sprech zu arbeiten. Das liesst man nicht mal eben so wenn man nicht sowieso schon Informatik studiert. Wie oft empfiehlt es sich da natuerlich auf englischsprachige Buecher auszuweichen. Aber natuerlich, man lernt dann etwas complexes in einer fremden Sprache. Macht es nicht einfacher. .-) Olaf
Olaf schrieb: > Allerdings ist der Aufwand > erheblich. So erheblich das sich vielleicht mancher der damit nicht > jeden Tag 8h zutun hat fragt ob es sich lohnt. Womit Du unmittelbar ein Folgeproblem der hohen Sprachkomplexität ansprichst. Schon deshalb wird C++ und Konsorten nie die breite Masse erreichen und werden die Spalten der Stellenanzeigen für (entsprechende) Programmierer voll bleiben.
M.C. schrieb: > Schon deshalb wird C++ und Konsorten nie die breite Masse > erreichen Ich sach nur "Arduino" ... ............ M.C. schrieb: > immer in einem sinnvollen Verhältnis zur > Aufgabenstellung bzw. der letztendlichen Lösung? Klare Antwort: Nein. Ist das Pferd ein gutes Reittier? NEIN! Es kann nur wenig Last tragen und ist schnell erschöpft. Ist der Elefant ein gutes Reittier? NEIN! Der frisst so viel, und ist zu hoch. Ist der Esel ein gutes Reittier? NEIN! Der scheiß Passgang, der nervt, und störrisch ist ein Esel auch. ------------ Du merkst? Offensichtlich hast du keinen Bock auf OOP reiten. Weil dir das nicht schmeckt, möchtest du es als "Dreck" klassifizieren und allen anderen madig machen. Sorry, dass ich dir das sagen muss: Du bist ein Priester auf verlorenem Posten. Merke Zwei: Untersuche andere Sprachen! Bei jeder wirst du Haare in der Suppe finden. Tipp: Wenn du eine solche, egal welche, Sprache nutzen möchtest, dann konzentriere dich auf die Möglichkeiten, welche sie bietet. So kommt man zu Lösungen. Konzentrierst du dich auf die Haare in der Suppe, zeigt es nur, dass du diese Sprache ablehnst. So offenbarst du eine verzerrte Wahrnehmung, weit von jeder Objektivität entfernt. Deine Ablehnung sagt mehr über dich aus, als über die Sprache.
Arduino Fanboy D. schrieb: > Ich sach nur "Arduino" ... Das hat ja nun mit vollwertiger C++ Programmierung herzlich wenig zu tun. > Weil dir das nicht schmeckt, möchtest du es als "Dreck" klassifizieren > und allen anderen madig machen. Ja es ist natürlich unangenehm wenn Schwachstellen benannt werden. Habe ich es deshalb als "Dreck" klassifiziert? Natürlich nicht. > Konzentrierst du dich auf die Haare in der Suppe Schön! Auch in der OOP-Suppe schwimmen also Haare. Mehr Zugeständnis kann man einem OOP-Priester wie Dir wohl an dieser Stelle nicht abringen :)
M.C. schrieb: > Das hat ja nun mit vollwertiger C++ Programmierung herzlich wenig zu > tun. Wie beurteilst du das? Meine kleinen AVR Arduinos werden z.Zt. mit C++17 bespielt. M.C. schrieb: > Auch in der OOP-Suppe schwimmen also Haare. Natürlich! Wer suchet, der findet! > Wer will, findet Wege. > Wer nicht will, Gründe. M.C. schrieb: > einem OOP-Priester wie Dir Mir ist es komplett scheißegal, wer welche Sprache nutzt. Mein Bedarf Leute zu bekehren ist, wenn vorhanden, dann nur marginal. Also nix Priester. Übrigens: Der Thread heißt: > hardwarenah, objektorientiert programmiert Und du jallerst die ganze Zeit darauf rum, welcher Mist das doch ist. Anstatt Wege aufzuzeigen .... So wie du dich gibst, könnte ich vermuten, dass der Apfel zu hoch am Baum hängt, und deine Gehirnwindungen zu kurz sind, um da ran zu kommen. Also hast du beschlossen, dass der Apfel faul, oder zu sauer ist. Und jetzt nutzt du das Forum dazu um deine irrationale Entscheidung auf alle anderen zu projizieren.
@ufuf: Wenn Dir hier nichts anderes mehr übrig bleibt als auf diesem Niveau zu "argumentieren" spricht das auch für sich. Ein Wort noch zum Thema vielgerühmter OOP-Produktivität. Die hätte ich gerne mal im Verhältnis zu gescheiterten OOP Projekten generell und zu erzielten Ergebnissen gesehen. Gibt es da irgendwelche Statistiken? Wenn ich mir jedenfalls manche lahme Software auf meinem PC so anschaue frage ich mich schon, ob diese in OOP Manier längst zu komplex gestrickt ist, warum sie einen Riesen- Platz belegt und man auch auf Fehlerbehebung ewig wartet. AtmelStudio wär da so ein Kandidat...
> Ich sach nur "Arduino" ...
Und ich lieg vor lachen auf dem Boden.
Und jetzt? Sorry, bloss weil da zufaellig ein C++ Compiler
genutzt wird und man dort theoretisch in C++ voll krasse Projekte
durchziehen koennte, heisst das ja nicht das es einer macht.
Ich seh bei Arduino immer nur C irgendwie zusammenkopiert. Eigentlich
ist gerade Arduino ein schoenes beispiel das die objektorientierte Denke
die breite Masse der Nutzer eben nicht erreicht. Und nein, es hilft da
nicht wenn du irgendwo ein vereinzeltes Beispiel auftreibst das zeigt
das es technisch moeglich ist.
Olaf
Arduino Fanboy D. schrieb: > Übrigens: > Der Thread heißt: > hardwarenah, objektorientiert programmiert Richtig. Ein prominentes Beispiel dafür, daß sich beide Eigenschaften weniger gut vertragen, findet sich im großen Markt automobiler Steuergeräte-Software. Da hat sich das ach so großartige OOP eben gerade nicht durchsetzen können. Da bleibt C bis heute die Sprache der Wahl, wenn auch im verschärften MISRA-Standard.
Olaf schrieb: > Ich seh bei Arduino immer nur C irgendwie zusammenkopiert. Niemand, auch du nicht, sieht die Realität. Sondern nur ein durch Erfahrung gefiltertes Bild, generiert durch eine beschränkte Wahrnehmung/Sinne. Soviel zu dem "immer"! Olaf schrieb: > Und nein, es hilft da > nicht wenn du irgendwo ein vereinzeltes Beispiel auftreibst das zeigt > das es technisch moeglich ist. OK, Gegenargumente sind per Definition unerwünscht.... Das macht natürlich einen Dialog nicht gerade einfacher. Vielleicht solltest du zur Kenntnis nehmen, dass Arduino nicht so sehr für gelernte Programmierer gedacht ist, sondern eher für die breite Masse, also eher für Fachfremde. Man kann nicht erwarten, dass Fachfremde sofort/instant genialen Code raus hauen. Und wenn du das erwartest, solltest du evtl. deine Haltung überprüfen. Dir begegnen, z.B. hier im Forum hauptsächlich Anfänger. Deren Code siehst du hier und auch in tausenden weiteren Ecken im Netz. Wie lange braucht es, bis man ein fähiger Programmierer ist? 3 Jahre, oder eher 5? Bis man ein einigermaßen sattelfester Hardwareentwickler ist? 3 Jahre, oder eher 5? Plus, für jede Sprache, für µC, usw, nochmal ein paar Monate. Nach der Zeit sagen wir mal 10 Jahre, könnte der Lernende sich zu der Ausnahme entwickelt haben, die du gerne sehen möchtest. Aber genau der/die/das benötigt kein Forum mehr für seine Fragen. Du siehst also eigentlich nur die Anfänger.
Ein Punkt, wo OOP scheitert, sind die alltäglichen Sonderlocken. Die OOP Lehrbücher zeigen immer schön, wie man Eigenschaften und Regeln vererbt. Aber sie zeigen nicht, wie man Sonderlocken umsetzt, die sich über mehrere Ebenen der ganzen Objekt-Hierarchie verteilen. Mit dem Überschreiben einzelner Methoden ist es oft nicht getan. Ich musste schon "kleine" Änderungen umsetzen, die sich durch 20 Quelltext-Dateien durchzogen. Da kommt schnell die Bemerkung auf, dass das Programm schlecht strukturiert sei. Aber damit ist niemandem geholfen. Programme, die mit voller Absicht von einem anderen Kundenprojekt geforkt wurden und dann 12 Jahre lang gewachsen sind, sehen eben furchtbar aus. Wer billig will, bekommt auch billig, dessen kann ich mich als Entwickler nicht verweigern. Ich kann nicht mal eben 200.000 Zeilen Code umschreiben, nur um eine kleine Änderung mit 2 PT Umsatz schöner zu machen. Dennoch möchte ich nicht auf OOP verzichten.
Arduino Fanboy D. schrieb: > Niemand, auch du nicht, sieht die Realität. > Sondern nur ein durch Erfahrung gefiltertes Bild, generiert durch eine > beschränkte Wahrnehmung/Sinne. Klasse. Nun lieg ich aber auch am Boden vor lachen. Was für eine wohlfeile Erklärung. Zwischen den Zeilen steht wohl daß da jemand durchblickt der kein Anfänger mehr ist :) > OK, Gegenargumente sind per Definition unerwünscht.... Wer definiert das? Davon abgesehen ist von sachlichen Gegenargumenten bei Dir weit und breit nichts zu sehen. > Vielleicht solltest du zur Kenntnis nehmen, dass Arduino nicht so sehr > für gelernte Programmierer gedacht ist, sondern eher für die breite > Masse, also eher für Fachfremde. Vielleicht solltest Du zur Kenntnis nehmen daß gerade deshalb Arduino kein Argument für den Erfolg vollwertiger C++ Programmierung ist. > Du siehst also eigentlich nur die Anfänger. Soll man das jetzt als Sach-"Argument" verstehen?
Stefan ⛄ F. schrieb: > Ein Punkt, wo OOP scheitert, sind die alltäglichen Sonderlocken. > Die OOP Lehrbücher zeigen immer schön, wie man Eigenschaften und Regeln > vererbt. Aber sie zeigen nicht, wie man Sonderlocken umsetzt, die sich > über mehrere Ebenen der ganzen Objekt-Hierarchie verteilen. Mit dem > Überschreiben einzelner Methoden ist es oft nicht getan. > Ich musste schon "kleine" Änderungen umsetzen, die sich durch 20 > Quelltext-Dateien durchzogen. Das klingt auch nicht gerade nach Produktivität. Leider befeuert Komplexität immer auch den Teufel im Detail. Deshalb: Keep it simple! > Dennoch möchte ich nicht auf OOP verzichten. Ich möchte hier nicht falsch verstanden werden. Niemand will Konzepte der OOP madig machen. Aber alles hat eben Vorteil und Preis.
M.C. schrieb: > Deshalb: Keep it simple! Das ist der Stil, den ich bevorzuge, wo immer ich darf. In jeder Projektbesprechung thematisiere ich das mit deutlich positiven Ergebnissen. Mein Chef tickt da genau so. Das Problem sind angeblich erfahrene Consulter, die unser GF Monatelang alleine an einem Projekt fummeln lässt. Die versauen einzelne teile oft mit ihren überkomplexen akademischen Lösungen. Und natürlich ist einer unserer größten Feine die Idee, man könne 10 Jahre alte Programme als Basis für ein neues nehmen und weitere 10 Jahre weiter bauen, ohne mal über die Struktur und Aktualität der Methoden und Bibliotheken nachzudenken. Zugleiche verkauft man dem Kunden auf dem Papier selbstverständlich stets allerneueste Technologie. Das hasse ich. Ich brauche keineswegs immer die allerneuesten Sachen, aber alten Käse mehrfach überbacken und das dann "neu" zu nennen, geht mir zu weit.
M.C. schrieb: > Davon abgesehen ist von sachlichen Gegenargumenten > bei Dir weit und breit nichts zu sehen. Bei dir auch nicht. Kein einziges! Nur Behauptungen, ohne Begründungen. Auf Nachfragen reagierst du gar nicht. Danke und Tschüss,
Arduino Fanboy D. schrieb: > Nur Behauptungen, ohne Begründungen. Dazu muß man eine Begründung und Beispiele überhaupt erstmal sehen wollen. Du mußt lernen, daß es mit den prinzipiellen Möglichkeiten einer Sprache eben nicht allein getan ist. Der gelungene Entwicklungsprozeß samt gutem Ergebnis hat viele Zutaten, ist anwendungsabhängig und muss möglichst reibungsfrei durch die vorhandenen Hirnwindungen flutschen ?
M.C. schrieb: > Dazu muß man eine Begründung und Beispiele überhaupt erstmal sehen > wollen. Du mußt lernen, daß es mit den prinzipiellen Möglichkeiten > einer Sprache eben nicht allein getan ist. Der gelungene > Entwicklungsprozeß samt gutem Ergebnis hat viele Zutaten, ist > anwendungsabhängig und muss möglichst reibungsfrei durch die vorhandenen > Hirnwindungen flutschen ? Was soll das bedeuten? Sprichst du hier der gesamten Arduino Gemeinde die Lernfähikeit ab? Oder der Sprache C++ die Lernbarkeit? Welches Ziel verfolgst du mit deinen Ansagen?
Arduino Fanboy D. schrieb: > Bei dir auch nicht. > Kein einziges! > > Nur Behauptungen, ohne Begründungen. > Auf Nachfragen reagierst du gar nicht. > > Danke und Tschüss, Da der TO ja eh raus ist: Wenn Ihr OOP thematisieren wollte, müsstet ihr euch erstmal einig sein, welchen Aspekt ihr überhaupt diskutieren wollt und wo Konsens besteht. Es wechselt wild zwischen OOP als Konzept, OOP-Unterstützung durch Sprachen, Effizienz, Wartbarkeit, etc. Noch dazu, wo jeder von Euch ein anderes Set an OOP-Merkmalen im Kopf hat. Und z.B. Autosar und Datenbanken zeigen es so plakativ: Autosar ist überwiegend in plain C, die Konzepte (Objekte mit Methoden und Nachrichten) können aber sehr wohl als OO verstanden werden. Typische Datenbanken können gerne in OOP programmiert sein, die Datenbank selber ist aber genau das Gegenteil von OO. Konsens sollte zuerst darüber erzielt werden, dass es Gebiete gibt, wo OOP super ist, und welche, wo es deplaziert ist. Und dann könnt ihr ja gerne (zu unser aller nutzen) die Trennlinie ausloten. Dass es daneben gute und schlechte Software gibt, Prozedural und OOP, geschenkt. Dass Verallgemeinerung erst dann Sinn macht, wenn man Verallgemeinern kann (also mehr als 2 unterschiedliche Fälle überblicken kann oder kennt), sollte jedem einleuchten. Dass ein Anfänger seinen Bubblesort nicht sofort als DLL Threadfest programmiert, auch.
A. S. schrieb: > Da der TO ja eh raus ist: Wenn Ihr OOP thematisieren wollte, müsstet ihr > euch erstmal einig sein, welchen Aspekt ihr überhaupt diskutieren wollt > und wo Konsens besteht. Es wechselt wild zwischen OOP als Konzept, > OOP-Unterstützung durch Sprachen, Effizienz, Wartbarkeit, etc. Das wäre mal was! Wobei das mit der Einigkeit wohl nicht so läuft..... Was mich betrifft, mag ich die OOP Konzepte. Die Sprache ist mir dabei recht egal. C++ halte ich für eine eher hässliche Sprache. Bin allerdings ein Fan der Templates, bzw. der Möglichkeiten, die damit einher gehen. z.B. dass man so viel dem Kompiler überlassen kann Je kleiner der µC desto interessanter ist das. Effizenz und Wartberkeit kommt mit der Zeit. Ist auch eine Frage der Anforderungen. Ich sehe da keine pauschalen Ansagen leuchten.
Arduino Fanboy D. schrieb: > Bin allerdings ein Fan der Templates, bzw. der Möglichkeiten, die damit > einher gehen. > z.B. dass man so viel dem Kompiler überlassen kann > Je kleiner der µC desto interessanter ist das. Erläutere das doch mal an einem Beispiel. Wo da bei kleinen MCs der Vorteil gegenüber konventioneller Programmierung liegt. Und was dem Compiler überlassen wird.
Adam schrieb: > Erläutere das doch mal an einem Beispiel Ein für mich relevantes Beispiel, ist die Arduino Pin Nummerierung. Die kann man mögen, oder hassen. Aber sie ist auf jedem Board aufgedruckt. Und damit ein unvermeidliches Dingen, wenn man sich mit anderen Arduino Jüngern unterhält. Allerdings ist dieses recht teuer. Sie kostet Arrays im Flash und die Funktionen sind, naja, langsam. Das lässt sich über Templates und andere C++ Sprachmitteln angehen. Adam schrieb: > Vorteil Weniger Flash Bedarf Kein RAM Bedarf (die original Arduino Funktionen benötigen Stack) Bessere Performance Weniger Schreibarbeit im Projekt, damit weniger Flüchtigkeitsfehler Lesbarer, als direkte Portmaipulationen Naja.... Ist das ein Beispiel?
Na, mit Templates sind wir dann aber vollkommen weg von OOP. Und beim Thema, welch Programmiersprache (oder Konzept) äquivalentes zu bieten hat.
Ich sollte dazu sagen daß ich konventionell in C programmiere und von OOP keinen Schimmer habe. Arduino Fanboy D. schrieb: > Ein für mich relevantes Beispiel, ist die Arduino Pin Nummerierung. Was ist das Problem dabei? > Das lässt sich über Templates und andere C++ Sprachmitteln angehen. Wie wird das obige Problem damit denn nun genau gelöst. Was mich dabei besonders interessiert: Welchen Vorzug bieten diese Sprachmittel? Mach doch mal etwas Werbung dafür! Um noch gezielter zu fragen: > Weniger Flash Bedarf Was braucht gegenüber wem weniger Flash? > Kein RAM Bedarf (die original Arduino Funktionen benötigen Stack) Bestünde der mit purem C? > Bessere Performance Was hat gegenüber wem bessere Performance und warum? > Weniger Schreibarbeit im Projekt, damit weniger Flüchtigkeitsfehler Magst Du ein Beispiel geben was genau eingespart wird? > Lesbarer, als direkte Portmaipulationen Dito. Ein Beispiel bitte.
Adam schrieb: > Welchen Vorzug bieten diese Sprachmittel? Ich glaube kaum, dass man das in einem mikrocontroller.net-Post kurz (oder auch lang) beschreiben kann. Sprachen, die moderner sind als C, bieten dem Programmierer eine Vielzahl von Möglichkeiten und Techniken, die der Programmierer nutzen kann. Es geht dann auch tatsächlich nicht primär darum, dass diese Möglichkeiten immer und überall besser sind als bekannte C-Techniken. Aber es kann schon zu einem saubereren und lesbareren Programm beitragen. Natürlich kann man mit komplexen Techniken und Paradigmen ein Programm auch unlesbarer und schlechter machen. Es kommt immer darauf an, was der Programmierer beherrscht und wie gut er es beherrscht. Die Programmiersprache ist nur ein Werkzeug. Eine CNC-Maschine ist nicht besser als ein Hammer. Aber man kann mit einer CNC-Maschine Dinge tun, die mit einem Hammer sehr umständlich sind.
Adam schrieb: > Was ist das Problem dabei? Habe ich genannt! Adam schrieb: > Was braucht gegenüber wem weniger Flash? Die Template + OOP Lösung gegenüber der Standard Arduino API Adam schrieb: > Bestünde der mit purem C? Wenn in C Funktionen aufgerufen werden wird der Stack beansprucht. Das macht keinen Unterschied zu C++ Am Rande: Die originalen sind C Funktionen Adam schrieb: > Dito. Ein Beispiel bitte. Ich empfinde > led.toggle(); lesbarer als > PINB = (1<<PB5); Einen Teil der anderen Fragen beantwortet: Beitrag "Re: Geschwindigkeit IO-Zugriff"
Arduino Fanboy D. schrieb: > Adam schrieb: > Was ist das Problem dabei? > > Habe ich genannt! Ich verstehe es nicht. Du sprichst in Rätseln. > > Adam schrieb: > Was braucht gegenüber wem weniger Flash? > > Die Template + OOP Lösung Ebenso unklar was das nun meinen soll. > Wenn in C Funktionen aufgerufen werden wird der Stack beansprucht. > Das mach keinen Unterschied zu C++ > Am Rande: Die originalen sind C Funktionen Also würde ich mit OOP hier RAM sparen können !? > Ich empfinde > led.toggle(); > > Als lesbarer als > PINB = (1<<PB5); Da gebe ich Dir schon Recht aber das lässt sich im Rahmen von C oder mit einem Makro ebenso erreichen > Beitrag "Re: Geschwindigkeit IO-Zugriff" Darin finde ich aber nichts was mir den Vorteil von OOP gegenüber C erklären würde...
Adam schrieb: > Darin finde ich aber nichts was mir den Vorteil von OOP gegenüber C > erklären würde... Aha... Adam schrieb: > Da gebe ich Dir schon Recht Also dioch. Adam schrieb: > das lässt sich im Rahmen von C oder mit > einem Makro ebenso erreichen Ja, wenn Makro der Heilsbringer ist... Zeige doch mal in C, ohne Makros. Bin interessiert wie das dann aussieht! Wie du da ein digitalWrite(13,!digitalRead(13)); zu einem PINB = (1<<PB5); welches in 1 ASM Statement zerfällt, umformst.
MaWin schrieb: > Es geht dann auch tatsächlich nicht primär darum, dass diese > Möglichkeiten immer und überall besser sind als bekannte C-Techniken. Oh. Darauf hatte ich schon gehofft! > Aber es kann schon zu einem saubereren und lesbareren Programm > beitragen. Natürlich kann man mit komplexen Techniken und Paradigmen ein > Programm auch unlesbarer und schlechter machen. Ja die Kosmetik nimmt sich also in beiden Fällen nichts? Denn man kann es überall gut oder schlecht schreiben? > Die Programmiersprache ist nur ein Werkzeug. Eine > CNC-Maschine ist nicht besser als ein Hammer. Aber man kann mit einer > CNC-Maschine Dinge tun, die mit einem Hammer sehr umständlich sind. Daher nochmal meine Frage: Adam schrieb: > Arduino Fanboy D. schrieb: > Bin allerdings ein Fan der Templates, bzw. der Möglichkeiten, die damit > einher gehen. > z.B. dass man so viel dem Kompiler überlassen kann > Je kleiner der µC desto interessanter ist das. > > Erläutere das doch mal an einem Beispiel. > Wo da bei kleinen MCs der Vorteil gegenüber konventioneller > Programmierung liegt. Und was dem Compiler überlassen wird. Welchen Vorteil bietet die "CNC Maschine" OOP gegenüber dem "Hammer" C auf kleinen MCs?
Arduino Fanboy D. schrieb: > Ja, wenn Makro der Heilsbringer ist... > > Zeige doch mal in C, ohne Makros. > Bin interessiert wie das dann aussieht! > Wie du da ein digitalWrite(13,!digitalRead(13)); zu einem PINB = > (1<<PB5); welches in 1 ASM Statement zerfällt, umformst. Das würde ich in C als Funktion definieren. Ich bevorzuge aber Makros. Was ist dagegen einzuwenden? Wegen dieser Schreibkosmetik würde ich jetzt ungern OOP lernen...
Arduino Fanboy D. schrieb: > Wie du da ein digitalWrite(13,!digitalRead(13)); zu einem PINB = > (1<<PB5); welches in 1 ASM Statement zerfällt, umformst. Generell mittels ganz normaler Funktionen und Link Time Optimization (LTO). Wenn die Funktionen nur eine Portzuweisung enthalten, werden die automatisch inlined und zerfallen in eine einzige asm-Instruktion. In diesem konkreten Beispiel müsste man aber ein PORTB read/write in ein PINB write umformen. Das geht mit C++ genauso wenig wie mit C.
Arduino Fanboy D. schrieb: > Ich empfinde >> led.toggle(); > lesbarer als >> PINB = (1<<PB5); Ein C-aquivalent wäre aber eher LedToggle(led); Und das auch nur, wenn es mehrere LEDs gibt. Sonst würde man auch einfach led.toggle() nehmen, auch wenn der Overhead in C ein wenig größer ist.
Adam schrieb: > Ja die Kosmetik nimmt sich also in beiden Fällen nichts? Denn man kann > es überall gut oder schlecht schreiben? Ja. Kommt halt auf den konkreten Fall an. Und bedenke auch, dass im Fall von C++ auch immer so gut wie alles möglich ist, was in C möglich ist. Man hat halt zusätzliche Möglichkeiten. > Welchen Vorteil bietet die "CNC Maschine" OOP gegenüber dem "Hammer" C > auf kleinen MCs? Welchen Vorteil bieten Äpfel gegenüber Birnen in Obstkörben?
Adam schrieb: > Das würde ich in C als Funktion definieren. > Ich bevorzuge aber Makros. Was ist dagegen einzuwenden? Wegen dieser > Schreibkosmetik würde ich jetzt ungern OOP lernen... Ob man Funktionen, Makros, Templates oder was auch immer verwendet, hat überhaupt gar nichts mit OOP zu tun.
Adam schrieb: > Welchen Vorteil bietet die "CNC Maschine" OOP gegenüber > dem "Hammer" C auf kleinen MCs? Nicht OOP bietet die nützlichsten Vorteile, sonder Templates und constexpr (wenn man einen Compiler benutzt, der C++17 kann). Damit berechnet der Compiler Dinge, die man bisher notdürftig durch Macros erledigte, die man ihm in C++-Code beschreiben kann. Wenn ich z.B. den Wert WGM eines AVR-Timers setzen will, dann sorgen Templates dafür, daß die auf 2Register verteilten WGM-Bits richtig einsortiert werden. Ich schreibe
1 | Timer::Wgm = Timer::WGM::CTC; |
2 | Timer::Cs = Timer::CS::DIV_8; |
Und der Compiler macht daraus
1 | ldi r16,0xii |
2 | out 0xnn,r16 |
3 | ldi r16,0xjj |
4 | Out 0xmm,r16 |
Auch wenn mehrbittige IO-Werte, die "layoutoptimiert" auf die IO-Pins verteilt sind, können so gebaut werden. Änderungen an der Pin-Belegung können gravierende Änderungen am Assemblercode notwendig machen, die mir der GCC in typisch unter einer Sekunde erledigt. Viel Spaß mit dem Hammer. Wobei ich zugeben muß, daß mich daran auch interessiert, daß es geht und ich nicht davon leben muß. Beim Programmieren für's Leben wünsche ich mir aber manchmal die Templates von C++.
MaWin schrieb: > In diesem konkreten Beispiel müsste man aber ein PORTB read/write in ein > PINB write umformen. Das geht mit C++ genauso wenig wie mit C. led.toggle(); Ist eins... Machts mit PINB led.set(1); led.set(0); zerfallen zu PORTB Zugriffen C++ Zucker: led = 1; led = 0; if(led) tuwas(); Dafür muss man sich in C schon die Ärmchen ausreißen. Nehme ich mal an...
Es ging Eingangs Irgendwie um die Frage Hardwarenah, Objektorientiert. Man kann die Hardwarefeatures eines uC als Objekte betrachten: uart, SPI, I2C, Ports, usw. Die haben Eigenschaften wie Speed, Bitbreite, Modi,... und Methoden wie read/write/... Das wird in einem Objekt zusammengefasst, bei diesen Hardwareresourcen sollte man sich das leicht vorstellen können. Objekte sind Neue Typen, man kann wie bei einer Variablen viele eines Typs anlegen. Wenn ein anderes Objekt wie zB ein Sensor ein Schnittstellen Objekt braucht kann das dem Sensor als Zeiger oder Referenz mitgegeben werden. Das sieht im Code wesentlich eleganter aus und C++ ist strenger als C bei der Typprüfung, damit kann man schon einige Fehler vermeiden. Das sind für mich schon genug Gründe lieber OOP und C++ vs. C einzusetzen.
Carl D. schrieb: > Nicht OOP bietet die nützlichsten Vorteile, Schade. Da hatte ich mir jetzt von "objekt-programmiert" mehr erhofft. Irgendwelche Pin-Belegungsänderungen sehe ich jetzt nicht als Problem, möglicherweise sind meine AVRMegaController + Programme auch zu klein dafür :->
Und wenn man nur Arduino betrachtet, dann findet man Serial.print() in einer Hand voll Overloads für diverse Typen, statt z.B. serial_print_char() serial_print_string() serial_print_flash_string() serial_print_int16() serial_print_float() ...
:
Bearbeitet durch User
Mich stören bei C/C++ die zahlreichen Fallstricke. Zum Beispiel, dass unter bestimmten Bedingungen der falsche Standard Konstruktor oder Destruktor aufgerufen wird, wenn ich ihn nicht durch einen eigenen leeren virtuellen(!) überschreibe. Da wäre es vielleicht besser gewesen, gar keine impliziten Konstruktoren und Destruktoren zu haben. Andererseits habe ich überhaupt kein Problem, Speicher selber zu verwalten und Zeiger zu benutzen. Keine Ahnung warum, aber das fällt mir ganz leicht. Leztzendlich hat jede Programmiersprache ihre Tücken. Ich kann auch kaum darüber beklagen, dass ein Hammer blöd ist, weil man sich damit auf den Daumen schlagen kann. Ist halt so. Klar kann man Hammer oft durch weniger gefährliche Werkzeuge ersetzen, aber nicht immer.
Carl D. schrieb: > Und wenn man nur Arduino betrachtet, Da finden sich schon einige Dinge, welche mit C nicht oder nur umständlicher möglich sind. z.B. die EEPROM Abhandlung Mal abgesehen von den eher primitiven read und write Methoden Gibs noch get und put, welche beliebige Datentypen verwursten Oder die Operatoren Überladung:
1 | byte egal = EEPROM[22]; |
2 | EEPROM[22] = 42; |
3 | EEPROM[22]++; |
Adam schrieb: > Carl D. schrieb: >> Nicht OOP bietet die nützlichsten Vorteile, > > Schade. Da hatte ich mir jetzt von "objekt-programmiert" mehr erhofft. > Irgendwelche Pin-Belegungsänderungen sehe ich jetzt nicht als Problem, > möglicherweise sind meine AVRMegaController + Programme auch zu klein > dafür :-> Naja, wenn man das Problem wild verteilter Bits nicht kennt, dann bringt einem sowas nichts. Statt D4..D7 eines 4-Bit-Lcd auf PB0..3 nun auf PC1/PD3/PB3/PB2, weil es das Layout erfordert. Neu schreiben oder neu kompilieren. Und in jedem Fall die kürzest mögliche Version des Binärcodes, als bei PB0..3 einfach PORTB = ( PORTB & 0xFF ) | lcd_data; Im anderen Fall deutlich komplizierter. Dazwischen einmal make
Arduino Fanboy D. schrieb: > Carl D. schrieb: >> Und wenn man nur Arduino betrachtet, > Da finden sich schon einige Dinge, welche mit C nicht oder nur > umständlicher möglich sind. > z.B. die EEPROM Abhandlung > Mal abgesehen von den eher primitiven read und write Methoden > > Gibs noch get und put, welche beliebige Datentypen verwursten > > Oder die Operatoren Überladung: >
1 | > byte egal = EEPROM[22]; |
2 | > EEPROM[22] = 42; |
3 | > EEPROM[22]++; |
4 | >
|
Es ging mir nur um das allereinfachste, das mitgeliefert wird. In der Sprache kann man eben Dinge schreiben die bei anderen Sprachen als Spezialfall in der Sprachdefinition stehen müssen. Pascal WRITE verhält sich genau so, kann aber in Pascal nicht formuliert werden. Wobei das Serial.print mit Hilfe von variadic templates auch eine variable Anzahl von unterschiedlich typisierten Parametern verarbeiten kann. Aber letztendlich ist das wie mit Autos. Man kann mit jedem von A nach B fahren, aber manche (ich) machen das lieber smooth in Ledersitzen flach über dem Boden sitzend. Komfort kann man genießen, muß aber nicht.
Carl D. schrieb: > Komfort kann man genießen, muß aber nicht. 280 auf der Bahn geht mit einem A8 viel entspannter, als in einem Lotus. Ist eine Frage der Prioritäten. Eins meiner Lieblingsbeispiele: (auch wenn Peda gleich wieder aufschreit) OK, das ist jetzt kein Speicher Sparwunder, eher ein Beispiel für schnelle Entwicklung, oder auch Lesbarkeit, wenn man sich an den Stil gewöhnt hat
1 | /**
|
2 | * Basisprogramm:
|
3 | * Das Blink Beispiel aus der Arduino IDE
|
4 | *
|
5 | * Zusaetzliche nebenlaeufige Funktionalitaet:
|
6 | * Eine Ablaufsteuerung
|
7 | *
|
8 | * Nach betaetigen des Schalters startet die Absaugung und danach
|
9 | * die Maschine. Nach abschalten stoppt erst die Maschine und danach die
|
10 | * Absaugung
|
11 | *
|
12 | *
|
13 | * Ablaufdiagramm - Zeitdiagramm
|
14 | *
|
15 | * schalter _----------_____ Schalterstellung
|
16 | * absaugung _-------------__ Verzoegertes abschalten
|
17 | * maschine ____-------_____ Verzoegertes einschalten
|
18 | *
|
19 | * Der Schalter arbeitet invers und ist entprellt
|
20 | *
|
21 | */
|
22 | |
23 | #include <CombieTimer.h> |
24 | #include <CombiePin.h> |
25 | #include <CombieTypeMangling.h> |
26 | |
27 | using namespace Combie::Pin; |
28 | using namespace Combie::Timer; |
29 | using namespace Combie::Millis; |
30 | |
31 | TasterGND<2> schalter; // zwischen Pin und GND(invertierend) |
32 | OutputPin<3> absaugung; |
33 | OutputPin<4> maschine; |
34 | |
35 | |
36 | EntprellTimer entprell { 20_ms}; // Schalter entprellen |
37 | RisingEdgeTimer ton {500_ms}; // steigende Flanke wird verzoegert |
38 | FallingEdgeTimer toff { 3_sec}; // abfallende Flanke wird verzoegert |
39 | |
40 | void setup(void) |
41 | {
|
42 | schalter.initPullup(); |
43 | absaugung.init(); |
44 | maschine.init(); |
45 | pinMode(LED_BUILTIN, OUTPUT); // unveraendert aus Blink.ino |
46 | }
|
47 | |
48 | void yield(void) |
49 | {
|
50 | bool schalterMerker = entprell = schalter; |
51 | absaugung = toff = schalterMerker; |
52 | maschine = ton = schalterMerker; |
53 | }
|
54 | |
55 | void loop(void) // unveraendert aus Blink.ino |
56 | {
|
57 | digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level) |
58 | delay(1000); // wait for a second |
59 | digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW |
60 | delay(1000); // wait for a second |
61 | }
|
Arduino Fanboy D. schrieb: > Carl D. schrieb: >> Komfort kann man genießen, muß aber nicht. > 280 auf der Bahn geht mit einem A8 viel entspannter, > als in einem Lotus. Ist eine Frage der Prioritäten. > Aus dem Lotus-Land gibt es auch Rückenschonenderes > > EntprellTimer entprell { 20_ms}; // Schalter entprellen > RisingEdgeTimer ton {500_ms}; // steigende Flanke wird > FallingEdgeTimer toff { 3_sec}; // abfallende Flanke wird > Ja, userdefined literals, ganz vergessen, meine Timer laufen auch 10_ms oder 1_kHz oder auch 0.125_MHz
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Carl D. schrieb: >> userdefined literals > Syntaktischer Zucker, der allerfeinsten Sorte. Wieso? Weil ich mir dann den Kommentar sparen kann? Oder einen Timer nur mit einem Intervall oder einer Zeit geladen werden können? Typsicherheit statt "der macht was komisches, kann jemand helfen".
Carl D. schrieb: > Weil ich mir dann den Kommentar sparen kann? Ja 500_ms oder 3_sec ist intuitiv erfassbar Carl D. schrieb: > Typsicherheit Da muss man sich schon mehr kümmern, als nur das Suffix definieren. Ansonsten: Ja! Typsicherheit ist Gold wert.
Arduino Fanboy D. schrieb: > Carl D. schrieb: >> Weil ich mir dann den Kommentar sparen kann? > Ja > > 500_ms ist intuitiv erfassbar > > Carl D. schrieb: >> Typsicherheit > Da muss man sich schon mehr kümmern, als nur das Suffix definieren. > Ansonsten: Ja! > Typsicherheit ist Gold wert. Meine Fragen waren dem "Syntaktischen Zucker" geschuldet. Gerade das ist nämlich die typische Antwort derer, die den wahren Wert der UDLs gar nicht verstehen.
Carl D. schrieb: > Wieso? > Weil ich mir dann den Kommentar sparen kann? > Oder einen Timer nur mit einem Intervall oder einer Zeit geladen werden > können? > Typsicherheit statt "der macht was komisches, kann jemand helfen". Hätte eine simple Funktion nicht das Gleiche geschafft? UDLs scheinen mir bloß eine Aufblähung der Sprachkomplexität zu sein.
2 Fliegen mit einer Klappe, lassen sich so erwischen. Lesbarkeit + Typesicher Erhebliche Kosten bei der Entwicklung der Libraries. Einfache Anwendung. Kein Laufzeitnachteil.
Arduino Fanboy D. schrieb: > 2 Fliegen mit einer Klappe, lassen sich so erwischen. > Lesbarkeit + Typesicher Full ack > Erhebliche Kosten bei der Entwicklung der Libraries. Naja, mein Zeiten/Frequenzen in F_CPU ticks abgebildet war jetzt keine meisterliche Anstrengung. > Einfache Anwendung. > Kein Laufzeitnachteil. full ack
Carl D. schrieb: > war jetzt keine meisterliche Anstrengung. Ach, deine Gehirnwindungen haben die passende Form, das ist alles. Ein militanter C oder ASM Jünger versteht gar nicht worüber du redest.
Arduino Fanboy D. schrieb: > Ein militanter C oder ASM Jünger versteht gar nicht worüber du redest. Und weil er es nicht versteht muß es bekämpft werden.
Stefan schrieb: > Und weil er es nicht versteht muß es bekämpft werden. Das ist natürlich. So wie auch Unkraut. Alles unbekannte könnte gefährlich sein. Mit dem Hammer einmal feste drauf, und es beißt nicht mehr. (dabei ist es völlig egal, ob es überhaupt Zähne hat)
Stefan schrieb: > Arduino Fanboy D. schrieb: >> Ein militanter C oder ASM Jünger versteht gar nicht worüber du redest. > > Und weil er es nicht versteht muß es bekämpft werden. Es wäre schön wenn die Kandidaten so verwirrt wären, daß sie gar nicht antworten können.
ich bin traurig und überrascht, was ich losgetreten habe
A. S. schrieb: > Ich habe schon objektorientierte SW in Assembler gesehen und > Spaghetti-Code in C++. OOP ist keine Frage der Sprache, sondern der > Umsetzung. Hat ja auch keiner behauptet... ;-) Das Ganze ist auch ein Äpfel-Birnen-Vergleich, schließlich ist OOP ein Paradigma und HW-Nähe nicht.
Bild schrieb: > ich bin traurig und überrascht, was ich losgetreten habe Alles OK. Von Übereinstimmung, bis Grabenkämpfe, alles dabei.
Beitrag #6230022 wurde von einem Moderator gelöscht.
WohnraumLenkung schrieb im Beitrag #6230022:
> Meine Wohnung ist so klein, -ich muss hardwarenah programmieren.
Räumlich HW-nah und C++ geht gut zusammen. Läuft alles auch auf kleinen
Notebooks. ;-)
Beitrag #6230033 wurde von einem Moderator gelöscht.
WohnraumLenkung schrieb im Beitrag #6230033: > Carl D. schrieb: > >> Räumlich HW-nah und C++ geht gut zusammen. > > C++ ?? > > Nein, das ist mir eine Nummer zu groß. Selbst C ohne ++ kriege ich hier > nicht unter. Daß solche Wohnverhältnisse überhaupt erlaubt sind....
Carl D. schrieb: > Es wäre schön wenn die Kandidaten so verwirrt wären, daß sie gar nicht > antworten können. Hach... Das wird nicht klappen. Der Grund: Was außerhalb der Wahrnehmung liegt, kann nicht zur einer Verwirrung beitragen.
Ich hasse OOP Ich hasse Arduino Ein anderes Wort für Templates: Abschaum!
Minus M. schrieb: > Ich hasse OOP > Ich hasse Arduino > Ein anderes Wort für Templates: Abschaum! Dann hätten wir das ja auch endlich mal geklärt.
Wenn ein Kenner hier mal die Güte hätte: Was sind überhaupt Templates, ganz einfach erklärt?
Adam schrieb: > Was sind überhaupt Templates, ganz einfach erklärt? Erste Näherung: Codegeneratoren, welche im Kompiler laufen, bzw. von diesem verwurstet werden. Der zweite Schritt: Eine Turing vollständige Maschine, innerhalb von C++. (welches erst nach der Erfindung der Templates erkannt wurde)
Arduino Fanboy D. schrieb: > Adam schrieb: > Was sind überhaupt Templates, ganz einfach erklärt? > > Erste Näherung: > Codegeneratoren, welche im Kompiler laufen, bzw. von diesem verwurstet > werden. Mit welchem Sinn? Für was? Bri diesem Fremdwort habe ich on diverser Literatur immer den Eindruck dass es nur mit weiteren Fremdworten erklärt werden kann und es aus diesem wechselseitigen Bezug kein Entrinnen gibt :)
Eine allgemeine Form:
1 | template<typename T> |
2 | bool vergleich(T &a,T& b) |
3 | {
|
4 | return a<b; |
5 | }
|
Jeder vergleichbare Type, also, für den es den Vergleichsoperator < gibt, lässt sich so vergleichen. Auch wenn der DatenType jetzt noch nicht bekannt ist (Morgen erfunden wird). Selbst Äpfel und Birnen kann man so vergleichen, wenn sie als Wägbar definiert sind. Ein C Programmier müsste für jeden Datentyp eine eigene Funktion schreiben. Das erledigt der Kompiler für uns C++ Heinis. -------- Oder zählen der Arrayelemente eines beliebigen Arrays. Egal welcher Datentype von dem Array gehalten wird.
1 | // drop in Ersatz fuer sizeof() Konstrukte
|
2 | template<typename ArrayType, size_t count> |
3 | constexpr size_t arrayCount(const ArrayType (&)[count]) |
4 | {
|
5 | return count; |
6 | }
|
Dieses natürlich zur Kompilezeit. Da wird kein Byte Code erzeugt.
MaWin schrieb: > Das klassische objektorientierte Programm besteht aus Konstruktoren (und > Destruktoren) in Klassen, also dynamischen Speicheranforderungen, Nö.
Axel S. schrieb: > Bild schrieb: >> lässt sich für einen Software-Entwurf eines Microcontrollers sagen, dass >> man hardwarenah, objektorientiert programmiert hat? > > Die Frage ist vollkommen sinnlos. Allgemein kann man sowas schon mal gar > nicht sagen, man muß immer eine konkrete Software betrachen. Es geht doch anscheinend um eine konkrete Software. > Dazu kommt noch, daß schon bei "objektorientiert" kein Konsens darüber > besteht, was man denn alles dazu zählen möchte und was nicht. Alan Kay sollte es wissen, denn der hat's erfunden: “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
Arduino Fanboy D. schrieb: > Ich weiß nicht, ob deine Fragestellungen und Behauptungen zielführend > sind. > Denn ich kenne dein Ziel nicht. Er ist an der OOP gescheitert, deswegen ist sie doof. ;-)
Peter D. schrieb: > Das beste OOP nützt nichts, wenn der Programmablaufplan nichts taugt. Das ist erstens nicht Aufgabe der OOP und gilt zweitens für jedes andere Paradigma ganz genauso. > Anders gesagt, OOP kann einem in keinen Fall das Denken abnehmen. Zu > überlegen, wie man ein Programm sinnvoll strukturiert, d.h. wann und wie > oft eine Funktion wirklich aufgerufen werden muß und wieviel CPU-Zeit > sie benötigt, interessiert das OOP nicht die Bohne. Das ist ja auch nicht ihr Job, und gilt, wie gesagt, auch für alles andere. Allerdings helfen gängige OO-Techniken, den Code besser und übersichtlicher zu strukturieren, den Code wiederverwendbarer zu gestalten und viele beliebte Fehler bereits zur Compilezeit erkennen (und idealerweise beheben) zu können.
Arduino Fanboy D. schrieb: > MaWin schrieb: >> Dann frag mal bei einer Versicherung oder einer Bank nach. > > Da wird die Frage von einem fetten Oracle (o.ä.) Brummer beantwortet. Meistens liegt sowas in Hana, Redis oder Ähnlichem.
MaWin schrieb: > Arduino Fanboy D. schrieb: >> Würde mich wundern, wenn der mit ASM bespielt wird. > > Die großen Datenbanken sind im Kern, da wo es auf Performance ankommt, > hochoptimiert. Ja, aber sie sind trotzdem zu langsam. Zusicherungen wie Transaktionssicherheit, Referentieller Integrität, MVCC, Write Ahead Logs, Query Optimization etc. haben nunmal ihren Preis. Deswegen erfreuen sich heute die NoSQL-Datenbanken wie etwa CouchDB, MongoDB, Elasticsearch, oder hochperformante In-Memory-Datenbanken wie Gridgain / Apache Ignite, Redis et al., welche solche Garantien nicht anbieten, zunehmender Beliebtheit.
M.C. schrieb: > Natürlich schließt die einfache Lösung Erweiterbarkeit und > Wiederverwendung ein wenn es denn gefordert ist. Das lässt sich > allerdings auch in prozeduralen Sprachen sicherstellen. Nach Larry Wall ist die Faulheit eine der Kardinaltugenden guter Entwickler. Darum designen die guten Entwickler ihren Code nicht nur dann wiederverwendbar, wenn das im Pflichtenheft steht... Und ja, in prozeduralen Sprachen ist das nicht unmöglich, aber aufwändiger. > Na wär auch abenteuerlich der breit angewandten OOP die Berechtigung für > ihre sinnvollen Einsatzzwecke > abzusprechen. Da gehört das Handling großer Datenstrukturen sicher dazu. Es ist einfach eine hervorragende Idee, Daten und die Funktionen, die sie be- und verarbeiten, zu Objekten zusammenzufassen. > Generell stellt sich aber immer die Overhead- oder Wasserkopf-Frage: > Steht der Verwaltungsaufwand, steht die Komplexität der Sprachmittel > (samt Folgeproblemen) immer in einem sinnvollen Verhältnis zur > Aufgabenstellung bzw. der letztendlichen Lösung? Klare Antwort: Nein. Genau. Deswegen sind OO-Programme sehr oft kürzer und lesbarer als prozedurale. > Nächstes Problem Abstrahierung: Kann das Zwischenschalten immer neuer > Softwareschichten die Effizenz und den Ressourcenverbrauch unangetastet > lassen? Klare Antwort: Nein. Es ist ja keine Softwareschicht, sondern nur eine andere Art, den Quellcode zu organisieren. Im Mikrocontrollerbereich ist es sogar so, daß jeder halbwegs gute Compiler die OOP schlicht wegoptimiert und das Kompilat hinterher identisch ist zu einem äquivalenten prozeduralen Code. > Die Eignung von OOP und Abstraktion für "menschliche Hirnwindungen" war > bereits angesprochen. Auch hier die klare Antwort und ganz im Gegenteil > zur ursprünglichen Absicht: Nein, sie ist nicht für jeden Kopf > kompatibel. Du solltest wirklich nicht von Dir auf andere schließen, ist kein guter Stil. Bitte hör' jetzt auf mit dem Getrolle, vielen Dank.
Olaf schrieb: > Und ich lieg vor lachen auf dem Boden. > > Und jetzt? Sorry, bloss weil da zufaellig ein C++ Compiler > genutzt wird und man dort theoretisch in C++ voll krasse Projekte > durchziehen koennte, heisst das ja nicht das es einer macht. Aber ja doch. Die meisten Arduinoprojekte nutzen C++, und zwar auch dann, wenn sie keine eigenen Klassen definieren. Die Arduino-Libraries sind nahezu alle in C++ geschrieben, und wer sie benutzt, der benutzt automatisch C++ -- auch wenn er das nicht bemerkt oder nicht versteht.
A. S. schrieb: > Konsens sollte zuerst darüber erzielt werden, dass es Gebiete gibt, wo > OOP super ist, und welche, wo es deplaziert ist. Und dann könnt ihr ja > gerne (zu unser aller nutzen) die Trennlinie ausloten. Wo wäre es denn zum Beispiel deplatziert? Für ein bisschen Pingewackel auf einem kleinen Tiny13? Da ist
1 | #include <Pin.hpp> |
2 | |
3 | int main(void) { |
4 | InputPin btn( PINDEF(B, 0) ); |
5 | OutputPin led( PINDEF(B, 1) ); |
6 | |
7 | while(1) { |
8 | if(btn.isHigh()) { |
9 | led.setLow(); |
10 | } else { |
11 | led.setHigh(); |
12 | }
|
13 | }
|
14 | return 0; |
15 | }
|
immer noch lesbarer als die äquivalente C-Implementierung. Sogar jemand, der nur minimale Programmiererfahrungen und gar keine mit AVRs hat, kann leicht verstehen, was dieses Miniaturprogramm tut. Und wenn man es mit dem gcc übersetzt, ist das Kompilat exakt identisch mit jenem eines äquivalenten C-Programms, das direkt auf DDRB arbeitet. Insofern erscheint es mir -- genau wie Dir -- sinnvoller, sich erst einmal darüber zu einigen, was OO überhaupt ist, anstatt einfach zu behaupten, daß es in bestimmten Domänen keinen Platz habe. OO hat zum Beispiel nichts mit dynamischer Allokation, Exceptionhandling oder der Standard Template Library von C++ zu tun...
Adam schrieb: > Arduino Fanboy D. schrieb: >> Das lässt sich über Templates und andere C++ Sprachmitteln angehen. > > Wie wird das obige Problem damit denn nun genau gelöst. Was mich dabei > besonders interessiert: Welchen Vorzug bieten diese Sprachmittel? Mach > doch mal etwas Werbung dafür! Um noch gezielter zu fragen: Templates in C++ sind Anweisungen an den Compiler, wie er eine bestimmte Klasse oder Funktion erzeugen soll, das hat aber im Kern nichts mit OOP zu tun. Ein Beispiel ist ein simples Funktionstemplate für eine Funktion max():
1 | template <typename T> |
2 | T max(T a, T b) { |
3 | T rv; |
4 | if( a < b ) { |
5 | rv = b; |
6 | } else { |
7 | rv = a; |
8 | }
|
9 | return rv; |
10 | }
|
Durch die Verwendung dieses Template habe ich jetzt max()-Funktionen, die ich auf alle möglichen Typen anwenden kann -- auf alle, die den Operator '<' unterstützen. Das können generische Typen wie char, int, float oder auch double sein, aber auch selbstdefinierte Typen (Klassen), die mit diesem Operator verglichen werden können.
Sheeva P. schrieb: > Wo wäre es denn zum Beispiel deplatziert? Für ein bisschen Pingewackel > auf einem kleinen Tiny13? Für sowas ist OOP gut. Und C++ durch seinen Focus auf beliebige Ersetzungen zur Compilerzeit eher effektiver. Alle Pins des uC auf x verschiedene Weisen nutzen zu können, da ist OOP gut. Negativ wird es, wenn man unerwartet in RTTI läuft, wenn der Kontrollfluss verloren geht, wenn ein Bezeichner aus 20 namespaces kommen könnte, ... .
A. S. schrieb: > Sheeva P. schrieb: >> Wo wäre es denn zum Beispiel deplatziert? Für ein bisschen Pingewackel >> auf einem kleinen Tiny13? > > Für sowas ist OOP gut. Und C++ durch seinen Focus auf beliebige > Ersetzungen zur Compilerzeit eher effektiver. > > Alle Pins des uC auf x verschiedene Weisen nutzen zu können, da ist OOP > gut. Negativ wird es, wenn man unerwartet in RTTI läuft, wenn der > Kontrollfluss verloren geht, wenn ein Bezeichner aus 20 namespaces > kommen könnte, ... . Es "nicht auf die Reihe bekommen" ist keine Eigenschaft der Sprache.
A. S. schrieb: > Sheeva P. schrieb: >> Wo wäre es denn zum Beispiel deplatziert? Für ein bisschen Pingewackel >> auf einem kleinen Tiny13? > > Für sowas ist OOP gut. Und C++ durch seinen Focus auf beliebige > Ersetzungen zur Compilerzeit eher effektiver. > > Alle Pins des uC auf x verschiedene Weisen nutzen zu können, da ist OOP > gut. Negativ wird es, wenn man unerwartet in RTTI läuft, wenn der > Kontrollfluss verloren geht, wenn ein Bezeichner aus 20 namespaces > kommen könnte, ... . Unerwartet in RTTI laufen? Den Kontrollfluß verlieren? Bezeichner aus 20 Namespaces? Was redest Du da bitte für einen, entschuldige, Unsinn? Unerwartete Dinge geschehen nur, wenn der Entwickler sein Werkzeug nicht beherrscht.
Sheeva P. schrieb: > Für ein bisschen Pingewackel > auf einem kleinen Tiny13? Da ist > #include <Pin.hpp> > > int main(void) { > InputPin btn( PINDEF(B, 0) ); > OutputPin led( PINDEF(B, 1) ); > > while(1) { > if(btn.isHigh()) { > led.setLow(); > } else { > led.setHigh(); > } > } > return 0; > } > > immer noch lesbarer als die äquivalente C-Implementierung. Na da haste ja gleich das schönste Beispiel ausgesucht. In Assembler ist das herrlich simpel
1 | sbi DDRB,1 |
2 | marke: sbis PINB,0 |
3 | cbi PORTB,1 |
4 | sbic PINB,0 |
5 | sbi PORTB,1 |
6 | rjmp marke |
Wer die I/O-Befehle "persönlicher" will kann sie noch durch ein Makro ersetzen. Es geht also auch wesentlich kürzer ohne gewaltigen Syntax-Bombast, Klammern-Irrgärten und Riesen-Zeilenverbrauch. Kurz, knapp und gerade deshalb verständlich. Nichts essentielles bleibt verborgen. Vor allem ist der Anwender dazu angehalten mit dem Datenblatt seines Controllers zu arbeiten statt >1000 seitige Hochsprachenbibeln zu pauken. In letzteren steht nämlich auch nicht drin welche Hardware-Features einen besonders effizienten Code auf dem ausgesuchten Controller ermöglichen würden. Das, liebe Päpste der kompliziert- intransparenten OOP Programmierung, nennt man wirklich zielführend... Das und nichts anderes ist Hardware-Nähe. Wenn hier "verständlichere Schreibweise" mit einem dicken Rucksack voller zuätzlicher Sprachbürokratie verkauft wird ist das doch einfach nur lächerlich.
Sheeva P. schrieb: > Unerwartet in RTTI laufen? Den Kontrollfluß verlieren? Bezeichner aus 20 > Namespaces? Was redest Du da bitte für einen, entschuldige, Unsinn? > Unerwartete Dinge geschehen nur, wenn der Entwickler sein Werkzeug nicht > beherrscht. ... um mal ein praktisches Beispiel zu demonstrieren wie schwer diese komplexen Sprachen zu beherrschen sind :)
Hallo, Sheeva P. schrieb: > Durch die Verwendung dieses Template habe ich jetzt max()-Funktionen, > die ich auf alle möglichen Typen anwenden kann -- auf alle, die den > Operator '<' unterstützen. Das können generische Typen wie char, int, > float oder auch double sein, aber auch selbstdefinierte Typen (Klassen), > die mit diesem Operator verglichen werden können. Das heißt also, das der Compiler den obigen Quell-Text durch die jeweils zuständige Methode der entsprechenden Klasse ersetzt? rhf
Roland F. schrieb: > Das heißt also, das der Compiler den obigen Quell-Text durch die jeweils > zuständige Methode der entsprechenden Klasse ersetzt? nicht unbedingt, nimm das einfache max Beispiel von Sheeva. Streiche die Zeile mit dem template und ersetze T durch int. Wenn du das max jetzt für float haben möchtest, kopierst du die Funktion und ersetzt int durch float. Genau das wird durch das template (Vorlage, Schablone) vereinfacht. Wenn max eine komplexere Funktion ist und die geändert werden muss, dann macht man die Änderung nur im template und alle Instanzen nehmen die Änderung mit.
Sheeva P. schrieb: > Den Kontrollfluß verlieren? Ich weiß nicht genau, was "verlieren" hier bedeutet.... Aber es ist schon so, dass sich gestandene prozedurale Programmierer im OOP Kontrollfluss verlieren können. Oder anders: Ihnen der Kontrollfluss eines OO Programms sich nicht sofort offenbart. Eine Ursache: Meist wird vom prozeduralen Programmierer ein Programmlaufplan gemalt, ein Flussdiagramm. Das Flussdiagramm ist eine Art Pseudocode. Dann wird das Flussdiagramm mit echtem Sprachcode geflutet. Im Anschluss hat man dann ein Programm, welches den Kontrollfluss aus dem Diagramm fast/möglichst 1:1, abbildet. In der OOP sieht das meist etwas anders aus. Dort werden die Klassen und Objekte zueinander in Beziehung gesetzt. Einerseits gibt es dort die Vererbung, welches eine Form der Beziehung darstellt. Das führt zu Baum artigen Bildern. Dann gibt es die Beziehungen zwischen den Objekten. Diese haben eher den Charakter von "Nachrichten". Und im Zuge dieser Benachrichtigungen, wird der Kontrollfluss von Objekt zu Objekt weiter gereicht. Z.B. die UML Diagramme sind geeignet um diesen Benachrichtigungsfluss bildlich darzustellen. An der Stelle kümmert man sich eher um die Interfaces der Klassen. Um das Vererbungsinterface, und das öffentliche Interface. Dieses "in Beziehung setzen" führt dazu, dass der Kontrollfluss nicht offen zu Tage tritt, sondern eher wie beim Staffellauf weiter gereicht wird. Klarer: Der Kontrollfluss ergibt sich automatisch aus den modellierten Beziehungen zwischen den Objekten. Erst innerhalb von Methoden liegt der Kontrollfluss offen vor einem. Es kann also gut sein, dass ein ungeübter OOPler, oder ein gestandener Prozeduraler, ein OO Programm untersucht, und sich lange damit abmüht den Kontrollfluss zu verstehen und aufzumalen. Sich eben genau dabei verirrt, oder verheddert. Denn der Programmierer des Wunderwerks hat sich gar nicht wirklich um den Kontrollfluss gekümmert, sondern eigentlich nur Interfaces geschaffen, welche miteinander kommunizieren. Allgemein: In der prozeduralen Programmierung liegt der Fokus eher auf dem Kontrollfluss. In der OOP liegt der Fokus eher auf den Beziehungen zwischen den Objekten.
Asm'ler schrieb: > Controller ermöglichen würden. Das, liebe Päpste der kompliziert- > intransparenten OOP Programmierung, nennt man wirklich zielführend... > Das und nichts anderes ist Hardware-Nähe. > Wenn hier "verständlichere Schreibweise" mit einem dicken Rucksack > voller zuätzlicher Sprachbürokratie verkauft wird ist das doch > einfach nur lächerlich. Moby geh deine Pillen nehmen.
Stefan ⛄ F. schrieb: > Ein Punkt, wo OOP scheitert, sind die alltäglichen Sonderlocken. Kommt drauf an. Wenn sie wirklich "alltäglich" sind, dann hat der Programmierer seinen Job schlecht gemacht, wenn er sie nicht bereits in der Basisklasse mit eingeplant hat. Allerdings: Gerade die Notwendigkeit, sowas schon in der Basisklasse mit einzuplanen, zeigt tatsächlich die Schwächen von OOP als Konzept. Dagegen wurden dann die Interfaces erfunden. In praktisch jeder OO-Sprache sind sie der einzige Weg, die streng hierarchische Vererbung zu umgehen. C++ als eierlegende Wollmilchsau (und u.a. deshalb praktisch vollkommen unlesbar sei mal außen vor). > Aber sie zeigen nicht, wie man Sonderlocken umsetzt, die sich über > mehrere Ebenen der ganzen Objekt-Hierarchie verteilen. Mit dem > Überschreiben einzelner Methoden ist es oft nicht getan. Das ist einfach: man lernt, wirklich programmieren zu können. Dann kann man auch Sachen umsetzen, die Änderungen an ganzen Klassen-Hierarchien erfordern. Das ist allerdings nix für die Hipster-Generation und die "agilen" Entwicklungsmodelle, die den Chefs so gefallen, weil sie da billige, austauschbare, geistig minderbemittelte "Programmierer" beschäftigen können... Sowas erfordert halt den Überblick über's Gesamtwerk und eine peinlich detaillierte Planung der nötigen Eingriffe mit Rücksichten auf mögliche "Seiteneffekte". > Programme, die mit voller Absicht von einem anderen > Kundenprojekt geforkt wurden und dann 12 Jahre lang gewachsen sind, > sehen eben furchtbar aus. Wer billig will, bekommt auch billig Das ist ein wahres Wort. Deswegen läuft das bei mir auch anders. Es gibt Backends (die von Kunde zu Kunde immer nur geringfügig modifiziert oder erweitert werden) und Frontends, die für jeden Kunden bestenfalls nur stark angepaßt werden (z.B. die "Stammdatenpflege") oder sogar komplett neu entwickelt werden (die eigentlichen Anwendungen). > kann ich mich als Entwickler nicht verweigern. Ich kann nicht mal eben > 200.000 Zeilen Code umschreiben, nur um eine kleine Änderung mit 2 PT > Umsatz schöner zu machen. Was ist "PT"? Peta-Teuro? Also für Peta-Teuro kriegt jeder Kunde von mir (nach Prüfung der Bonität) natürlich eine ideale Anwendung. Da wird nix recycled, da sind sogar alle Optimierungen im Preis inbegriffen. Nur leider: so viel wollte echt noch niemand zahlen...
c-hater schrieb: > > Was ist "PT"? Peta-Teuro? > PersonenTage ist die Einheit, in der Profis ihre Zeit an Kunden verrechnen. Die wissen was das ist.
Adam schrieb: > Wenn ein Kenner hier mal die Güte hätte: > Was sind überhaupt Templates, ganz einfach erklärt? Im Kern sind es eigentlich extrem aufgeblasene und sehr komplexe Makros. Sie heißen nur sehr verschämt nicht mehr so... Es handelt sich eigentlich um eine Sprache innerhalb einer anderen Sprache. Sprich: das Problem wird statt wie in C in zwei in drei Anläufen kompiliert. Scheint ein supertoller neuer Trick zu sein. Ist es aber nicht. Denn: nahezu jeder Makroassembler durchläuft auch zumindest zwei Iterationen auf Quelltextebene, bevor es an die Codegenerierung geht. Ja mehr noch: es gibt viele Assembler, die bei Bedarf auch noch mehr Iterationen machen können und damit zumindest das theoretische Potential haben, noch effizienteren Code zu erzeugen. Tatsächlich ist aber IMMER eher die Fähigkeit des Programmierers bestimmend für die Codeeffizienz...
Beitrag #6231738 wurde von einem Moderator gelöscht.
c-hater schrieb: > ..... Mach dir mal keine Sorgen, du bist nicht der einzige, der sich mit den C++ Templates etwas schwer tut. Wikipedia sagt zu Templates: https://de.wikipedia.org/wiki/Template_(C%2B%2B) Ein C++ Buch sollte tiefer gehen, und mehr mögliche Anwendungen zeigen. Etwas trocken, das Thema https://en.cppreference.com/w/cpp/language/template_parameters
Arduino Fanboy D. schrieb: > In der prozeduralen Programmierung liegt der Fokus eher auf dem > Kontrollfluss. > In der OOP liegt der Fokus eher auf den Beziehungen zwischen den > Objekten. Genau. Und es gibt Bereiche, in denen der kontrollfluss wichtiger ist, als die Beziehungen. Und dort sind oop halt second best. Dass man mit C++ auch anders könnte ist ja kein Argument für OO. Die Grenze läuft oft entlang der Steuerungstechnik und zwischen konkreten und rein virtuellen Objekten.
Carl D. schrieb: > PersonenTage ist die Einheit, in der Profis ihre Zeit an Kunden > verrechnen. Die wissen was das ist. Also, ich mache den Job jetzt seit 30 Jahren. Von dieser Einheit höre ich wirklich das erste Mal. Kann es sein, dass du bei irgendeinem dieser unsäglichen Consulter beschäftigt bist? Bosch? Telekom-Systems? Oder ähnliches Gelichter auf kleinerer Ebene? Wenn die Leute zu mir kommen, ist die Situation i.d.R. so, dass sie mindestens eines von diesen in Zusammenarbeit mit diesem Gelichter vollständig gescheiterteten Projekten vorweisen können. Design-Ziel nicht annähernd erreicht. Oft genug nichtmal die geforderte Funktionalität in vollem Umfang implementiert (das läßt sich immerhin einklagen). Und in aller Regel wurde sowohl Budget als auch Projektzeit massiv überschritten. Der agile Ansatz hat nur dafür gesorgt, dass fast alles Geld des Kunden weg ist, er nach wie vor aber ohne funktionierende Software da steht... Ja, OK, vieles davon liegt auch in der Inkompetenz des Kunden begründet. Nur hat dem niemand der teuren Consulter das nach teuerer Analyse gesagt... Wir fangen einfach mal an...
c-hater schrieb: > Also, ich mache den Job jetzt seit 30 Jahren. Von dieser Einheit höre > ich wirklich das erste Mal. Das finde ich sehr merkwürdig. Alle Kommerziellen Projekte, an denen ich mitgewirkt habe, wurden in Personentagen abgerechnet. Ich dachte, das macht jede Firma so. https://de.wikipedia.org/wiki/Personenstunde#Andere_Einheiten https://www.duden.de/rechtschreibung/Personentag Ich finde deine Lästereien über andere Entwickler unangemessen.
c-hater schrieb: > Also, ich mache den Job jetzt seit 30 Jahren. Von dieser Einheit höre > ich wirklich das erste Mal. Aber sicherlich hast du schon mal das verwandte man-hours gehört.
Mann-Tage, MT, ja. Mann-Jahre, -Stunden, alles ja. Personen soll wohl gegendert sein, gehört hab ich es noch nie.
c-hater schrieb: > Carl D. schrieb: . >> PersonenTage ist die Einheit, in der Profis ihre Zeit an Kunden >> verrechnen. Die wissen was das ist. . > Also, ich mache den Job jetzt seit 30 Jahren. Von dieser Einheit höre > ich wirklich das erste Mal. . > Kann es sein, dass du bei irgendeinem dieser unsäglichen Consulter > beschäftigt bist? Bosch? Telekom-Systems? Oder ähnliches Gelichter auf > kleinerer Ebene? . > Wenn die Leute zu mir kommen, ist die Situation i.d.R. so, dass sie > mindestens eines von diesen in Zusammenarbeit mit diesem Gelichter > vollständig gescheiterteten Projekten vorweisen können. Design-Ziel > nicht annähernd erreicht. Oft genug nichtmal die geforderte > Funktionalität in vollem Umfang implementiert (das läßt sich immerhin > einklagen). Und in aller Regel wurde sowohl Budget als auch Projektzeit > massiv überschritten. Der agile Ansatz hat nur dafür gesorgt, dass fast > alles Geld des Kunden weg ist, er nach wie vor aber ohne funktionierende > Software da steht... > > Ja, OK, vieles davon liegt auch in der Inkompetenz des Kunden begründet. > Nur hat dem niemand der teuren Consulter das nach teuerer Analyse > gesagt... > > Wir fangen einfach mal an... Ich bin überrascht, wie zwei Personen mit sehr ähnlicher Vita sich so unterschiedlich entwickeln können. Da hab ich echt Glück gehabt.
A. S. schrieb: > Dass man mit C++ auch anders könnte ist ja kein Argument für OO. Aber auch kein Argument gegen C++. Oder gegen die Verwendung von Templates. Betrachtet man nur das prozedurale Paradigma, dann ist C++ nahezu auf gleichen Niveau mit C. Arduino Fanboy D. schrieb: > Allgemein: > In der prozeduralen Programmierung liegt der Fokus eher auf dem > Kontrollfluss. > In der OOP liegt der Fokus eher auf den Beziehungen zwischen den > Objekten. Eigentlich wollte ich damit recht deutlich zum Ausdruck bringen, dass man sein Denken auf OOP umstellen darf, wenn man in der OO Welt klar kommen will. Die Prozedurale Sichtweise, will ich damit keineswegs abwerten. Sie hat ihren Sinn in einer prozeduralen Welt. Auch beim Bau von Methoden durchaus hilfreich, sind sie ja eigentlich auch nur Funktionen mit/in ihrem Objekt Kontext. In der Planungs-/Modellierungsphase ist die prozedurale Denke eher ein Hemmschuh. Meine Erfahrung: Diejenigen, welche am wenigsten ihre Denke auf die OO Sicht umstellen können/wollen schimpfen am lautesten gegen die OOP. Es ist ein bisschen so, wie mit der Rekursion. > Wer die Rekursion verstehen will, muss vorher die Rekursion verstanden haben. Dieser "Umstellung des Denkens" stehen oft Jahre gute/erfolgreiche prozedurale Erfahrung entgegen. Es ist ein Trieb, diese mitzuschleppen. Total menschlich. Aber hinderlich. Diesen Weg nicht zu gehen, ist keinesfalls ein Makel. Aber abwerten, ohne zu kennen, worüber man herzieht, ist schon eine Macke. Einige sagen, auch in C oder ASM, könne man OO programmieren. Ja! Zumindest kann man die OO Sicht zur Anwendung bringen. Aber da diese Sprache eigentlich jede Unterstützung/Sprachmittel dafür vermissen lassen, ist das ein recht steiniger Weg, und muss auch nicht hübsch aussehen.
Arduino Fanboy D. schrieb: > Zumindest kann man die OO Sicht zur Anwendung bringen. > Aber da diese Sprache eigentlich jede Unterstützung/Sprachmittel dafür > vermissen lassen, ist das ein recht steiniger Weg, und muss auch nicht > hübsch aussehen. Sieht sie sicher nicht aus. Ist im Gegenteil i.d.R. sogar kaum erkennbar. Zum Glück ist es aber bei PC-Software auch nur sehr selten nötig, soweit herabzusteigen bei der Optimierung. Ich kenne das eigentlich nur noch im Bereich image processing. Bei kleinen µC hingegen ist es die ultima ratio. Jedenfalls, wenn man sie wirklich ausnutzen will. Wer hier mit C oder C++ hantiert, verschenkt massiv Potential. So einfach ist das eigentlich... Nicht schön für Leute, die halt nur dies können, aber die objektive Wahrheit... Ich raste immer nur dann aus, wenn diese Leute das abstreiten...
https://www.geeksforgeeks.org/differences-between-procedural-and-object-oriented-programming/?ref=rp https://resources.saylor.org/wwwresources/archived/site/wp-content/uploads/2013/02/CS101-2.1.2-AdvantagesDisadvantagesOfOOP-FINAL.pdf https://www.csetutor.com/advantages-and-disadvantages-of-object-oriented-programming-language/ Eigentlich bin ich der Ansicht "...es hängt davon ab...";-) Wem halt die Programmierschnauze prozedural gewachsen ist, der wird eben lieber so seine Ansätze und Lösungen formulieren und so programmieren wollen. Diejenigen, die die Vorzüge von OOP in die Praxis umsetzen wollen, tun es halt eben auf ihre Art. Jeder muss also auf seine Art glücklich werden. Solange der Chef es bezahlt ist ja alles in Ordnung;-) Und ist es wirklich so ein großes persönliches Versagen, zugeben zu müssen, dass man aus der Zwangsjacke von Prozedural nicht heraus kann? Wer jahrzehntelang damit umging und es so gelernt hat, der wird es in der Mehrzahl der Fälle schwer haben ein guter OOP Architekt zu werden und soll eben in einer Firma arbeiten oder als Hobby dort bleiben wo man sich wohl fühlt. Prozedurales Denken ist für die meisten Menschen in Fleisch und Blut drin und lässt sich nicht so leicht entfernen. Man muss sich doch als Anhänger verschiedener Programmierparadigmen nicht andauernd gegenseitig in die Suppe spucken müssen und sich gegenseitig als Jünger verschiedener Methoden anerkennen und mit der Rechthaberei und Religionsstreit aufhören. Das ist nämlich kindisch. Die dokumentierten Vor- und Nachteile von OOP und PP sind ja schon lange der Schnee von gestern und man braucht sich nicht mehr darüber auslassen und muss man eben je nach den Umständen entsprechend abwägen. Wenn die Anwendung so läuft wie sie soll ist es doch eigentlich Schnuppe wie es unter der Motorhaube programmiert wurde. Nicht alle Anwendungen sind so kompliziert, als dass OO Denken unumgänglich notwendig wäre. Auch in der prozeduralen Welt lassen sich Probleme genau und effizient formulieren. In vielen Anwendungen ist Polymorphialität auch gar nicht soooo wichtig. Ist eher angenehm. Wer diszipliniert mit seinen Werkzeugen umgeht wird auch in der Nicht-OO Welt gut funktionierende Geräte und sauberen Quell Code entwickeln können. Also: Toleranz, Jungs! Die Welt ist groß genug für beide Faktionen.
Arduino Fanboy D. schrieb: > Mach dir mal keine Sorgen, du bist nicht der einzige, der sich mit den > C++ Templates etwas schwer tut. Wenn du glaubst, daß im mich Templates schwer tue, hast du definitiv nicht verstanden, was ich geschrieben habe... Und; viel schlimmer: nicht verstanden, was tatsächlich dahinter steckt.
Asm'ler schrieb: > In Assembler ist das herrlich simpel Wurde Dein Hausverbot denn schon aufgehoben, Moby?
Roland F. schrieb: > Sheeva P. schrieb: >> Durch die Verwendung dieses Template habe ich jetzt max()-Funktionen, >> die ich auf alle möglichen Typen anwenden kann > > Das heißt also, das der Compiler den obigen Quell-Text durch die jeweils > zuständige Methode der entsprechenden Klasse ersetzt? Nicht ganz. Tatsächlich schaut der Compiler, auf welche Datentypen ich die max()-Funktion anwende, und erzeugt für jeden dieser Typen die passende Funktion.
c-hater schrieb: > nicht verstanden, was tatsächlich dahinter > steckt. Ja, das ist die Frage, wer was nicht versteht... (oder auch nicht) c-hater schrieb: > Im Kern sind es eigentlich extrem aufgeblasene und sehr komplexe Makros. > Sie heißen nur sehr verschämt nicht mehr so... Unverschämter Weise ist diese Template Maschine Turing-Vollständig. Ist das dein Makro Apparat auch? Wenn nein, dann ist das schon eine erheblicher qualitativer Unterschied.
Arduino Fanboy D. schrieb: > Sheeva P. schrieb: >> Den Kontrollfluß verlieren? > > Ich weiß nicht genau, was "verlieren" hier bedeutet.... > > Aber es ist schon so, dass sich gestandene prozedurale Programmierer im > OOP Kontrollfluss verlieren können. > Oder anders: Ihnen der Kontrollfluss eines OO Programms sich nicht > sofort offenbart. Da sind wir aber wieder bei "sein Werkzeug beherrschen" und drehen uns im Kreis. Meine Güte, wenn die Prozeduralen die OOP nicht lernen wollen oder können, dann sollen sie es halt lassen, ist doch ihre Sache. Es ist halt nur ein bisschen dämlitsch, wenn sie die OOP nur aufgrund ihrer eigenen Unwilligkeit oder Unfähigkeit in Bausch und Bogen verdammen. "\(".)/"
Tech Noir schrieb: > Wem halt die Programmierschnauze prozedural gewachsen ist, der wird eben > lieber so seine Ansätze und Lösungen formulieren und so programmieren > wollen. Diejenigen, die die Vorzüge von OOP in die Praxis umsetzen > wollen, tun es halt eben auf ihre Art. Verzeihung, aber das ist Unfug. OO-Entwickler beherrschen natürlich auch die prozedurale Entwicklung und können daher jederzeit die der Problemstellung angemessene, ideale Herangehensweise wählen. Nur ein paar wenige, besonders engstirnige und / oder verbohrte Prozeduralentwickler wehren sich gegen die Objektorientierung und sind in ihren Möglichkeiten beschränkt.
Tech Noir schrieb: > Prozedurales Denken ist für die meisten Menschen in > Fleisch und Blut drin und lässt sich nicht so leicht entfernen. So ist das. Warum sollte man auch. Das ist gleichbedeutend mit einem schweren Mangel des OOP Werkzeugs gegenüber einfacheren Herangehensweisen. Das ausufernde OOP Verwaltungs/Organisations/Sprachinstrumentarium schafft neben der eigentlichen programmlogischen zudem eine zusätzliche künstliche Fehlerebene.
Sheeva P. schrieb: > Nur ein > paar wenige, besonders engstirnige und / oder verbohrte > Prozeduralentwickler wehren sich gegen die Objektorientierung und sind > in ihren Möglichkeiten beschränkt. Ich würde mal behaupten das ist engstirnig! > die der > Problemstellung angemessene, ideale Herangehensweise wählen OOP kommt als ideale Herangehensweise höchstens für das eine Prozent der Entwickler infrage die diese auch 100%ig beherrschen. Sonst ist da nämlich nur mit mittelmäßigem ressourcenfressenden Code zu rechnen.
M.C. schrieb: > OOP kommt als ideale Herangehensweise höchstens für das eine Prozent der > Entwickler infrage die diese auch 100%ig beherrschen. Sonst ist da > nämlich nur mit mittelmäßigem ressourcenfressenden Code zu rechnen. OMG. Glaubst du dein Gesülze wenigstens selbst? Keine Arbeit mehr und sauer weil man keine veralteten C Programmierer mehr braucht? Oder wieder nur der übliche Moby Müll?
M.C. schrieb: > Warum sollte man auch. Wenn du nicht weißt, warum du das solltest, oder nicht solltest, dann ist das dein Problem. Ganz persönlich, deine Entscheidung. Aber diese deine Entscheidung/Meinung, zu verallgemeinern und auf andere zu projizieren, ist einfach nur Blödsinn. Was hast du davon, die OOP so madig zu machen? Was ist dein Motiv?
Johannes S. schrieb: > OMG. Glaubst du dein Gesülze wenigstens selbst? Genau. Antworten diesen Kalibers ersetzen dann fehlende Argumente. Der Anwender bekommt genügend Beispiele für lahme und platzfressende OOP Software vorgesetzt.
Bla bla... Wirre Behauptungen ohne Substanz. Du erinnerst mich an das Trump Gesülze.
Arduino Fanboy D. schrieb: > Wirre Behauptungen ohne Substanz. Natürlich. Aber was man nicht wahrhaben will... Diese Art der Realitätsverweigerung hat was von Sekte. > Du erinnerst mich an das Trump Gesülze. Ja und Du mich an den Herrn zuvor. Gleiches Kaliber :(
Hallo, Sheeva P. schrieb: > Nicht ganz. Tatsächlich schaut der Compiler, auf welche Datentypen ich > die max()-Funktion anwende, und erzeugt für jeden dieser Typen die > passende Funktion. Aber wie macht der Compiler das? Für Datentypen wie Integer, Char, und Float kann ich das noch nachvollziehen, aber was ist z.B mit einem Datentyp "Verkehrsflugzeug"? Woher weiß der Compiler welches Verkehrsflugzeug "maximaler" ist? Ich stelle mir vor, das es in der Klasse "Verkehrsflugzeug", eine Methode existiert, die z.B. bestimmte Eigenschaften des verschiedener Verkehrsflugzeug-Objekte mit einander vergleicht und sich der Compiler dann beim Aufruf der max()-Funktion mit dem Datentyp "Verkehrsflugzeug" dann dieser Methode bedient. rhf
Hallo, Sheeva P. schrieb: > Es ist halt nur ein bisschen dämlitsch, wenn sie die OOP nur > aufgrund ihrer eigenen Unwilligkeit oder Unfähigkeit in Bausch > und Bogen verdammen. Naja, zumindest die mir bekannten (deutschen) Lehrmaterialien fördern auch nicht gerade die Lust und Bereitschaft sich mit einem vollkommen neuartigen Programmierparadigma auseinanderzusetzen. rhf
Roland F. schrieb: > Ich stelle mir vor, das es in der Klasse "Verkehrsflugzeug", eine > Methode existiert, die z.B. bestimmte Eigenschaften des verschiedener > Verkehrsflugzeug-Objekte mit einander vergleicht und sich der Compiler > dann beim Aufruf der max()-Funktion mit dem Datentyp "Verkehrsflugzeug" > dann dieser Methode bedient. Richtig, man kann in C++ Operatoren wie < oder > definieren und damit beliebige Objekte vergleichbar machen. Und dann funktioniert auch das max template.
Tech Noir schrieb: > Prozedurales Denken ist für die meisten Menschen in > Fleisch und Blut drin und lässt sich nicht so leicht entfernen. Das ist mir jetzt etwas zu kurz gedacht. Bei den meisten Menschen ist nämlich zuerst einmal das objektorientierte Denken drin, mithin: ein Objekt (sic!) mit den Methoden (sic!) zu benutzen, die es bietet. Prozedurale Denke muß man sich erstmal angewöhnen, und manchen fällt die Rückbesinnung dann leider schwer. M.C. schrieb: > Das ist gleichbedeutend mit einem schweren Mangel des OOP Werkzeugs > gegenüber einfacheren Herangehensweisen. Das ausufernde OOP > Verwaltungs/Organisations/Sprachinstrumentarium schafft neben der > eigentlichen programmlogischen zudem eine zusätzliche künstliche > Fehlerebene. Ah, Moby again.
Roland F. schrieb: > Sheeva P. schrieb: >> Nicht ganz. Tatsächlich schaut der Compiler, auf welche Datentypen ich >> die max()-Funktion anwende, und erzeugt für jeden dieser Typen die >> passende Funktion. > > Aber wie macht der Compiler das? Für Datentypen wie Integer, Char, und > Float kann ich das noch nachvollziehen, aber was ist z.B mit einem > Datentyp "Verkehrsflugzeug"? Woher weiß der Compiler welches > Verkehrsflugzeug "maximaler" ist? > Ich stelle mir vor, das es in der Klasse "Verkehrsflugzeug", eine > Methode existiert, die z.B. bestimmte Eigenschaften des verschiedener > Verkehrsflugzeug-Objekte mit einander vergleicht und sich der Compiler > dann beim Aufruf der max()-Funktion mit dem Datentyp "Verkehrsflugzeug" > dann dieser Methode bedient. Mir erschließt sich gerade nicht, wie ein allgemeingültiger Größenvergleich für Verkehrsflugzeuge aussehen sollte, aber wenn man einen implementieren würde (als Methode mit dem speziellen Namen "operator<", Stichwort: Operatorenüberladung), würde das natürlich so gehen. Ich persönlich würde allerdings vermuten, daß es sich bei so einer Implementierung aus den vorgenannten Gründen um einen Designfehler handelt -- nur weil etwas möglich ist, muß man es ja noch lange nicht machen, das kennt wohl jeder erfahrene Entwickler.
Flugzeuggröße könnte man Anhand von Eigenschaften wie Spannweite oder Passagierzahl festmachen. Aber sowas muss intuitiv sein, überladene Operatoren soll man nicht einfach einsetzen nur weil man es kann. Trotzdem macht sowas Sinn weil zb generische Listen dann Objekte nach Größe sortieren können.
Roland F. schrieb: > Ich stelle mir vor, das es in der Klasse "Verkehrsflugzeug", eine > Methode existiert, die z.B. bestimmte Eigenschaften des verschiedener > Verkehrsflugzeug-Objekte mit einander vergleicht und sich der Compiler > dann beim Aufruf der max()-Funktion mit dem Datentyp "Verkehrsflugzeug" > dann dieser Methode bedient. Der Vergleichsoperator kann innerhalb einer Klasse vorliegen oder als "freier" Operator. Siehe z.B.: https://en.cppreference.com/w/cpp/language/operators
Roland F. schrieb: > Sheeva P. schrieb: >> Es ist halt nur ein bisschen dämlitsch, wenn sie die OOP nur >> aufgrund ihrer eigenen Unwilligkeit oder Unfähigkeit in Bausch >> und Bogen verdammen. > > Naja, zumindest die mir bekannten (deutschen) Lehrmaterialien fördern > auch nicht gerade die Lust und Bereitschaft sich mit einem vollkommen > neuartigen Programmierparadigma auseinanderzusetzen. Deutschsprachige Lehrmaterialien kenne ich nicht und kann daher wenig dazu sagen; als ich seinerzeit mit OOP in C++ angefangen habe, hatte ich ein kleines Bändchen für den GCC (mit dem djgcc von DJ Bernstein auf Diskette ;-)) in englischer Sprache, das aber hauptsächlich C und nur sehr wenig C++ behandelt hat. Neugierig geworden, hab ich mich durch die Bücher von Bjarne Stroustrup gearbeitet, erst durch "The C++ Programming Language" und danach durch "The Design and Implementation of C++", beide auch auf Englisch, wobei vor allem letzteres wirklich großartig hinsichtlich eines tieferen Verständnisses gewesen ist... aber das ist schon lange her, und damals gab es ziemlich wenig bis keine deutschsprachige Literatur. Von jüngeren Kollegen habe ich allerdings gehört, daß "C++ für Dummies" [1] von Arnold Willemer (RWTH Aachen) recht gut sein soll; seine Website findest Du hier: [2]. Auch von Rainer Grimm habe ich im Linux-Magazin im Laufe der Zeit einige didaktisch hervorragend aufbereitete Artikel gelesen, vielleicht sind auch dessen Bücher ein guter Einstieg, sofern Du es nochmal versuchen möchtest. HTH, YMMV! [1] https://www.amazon.de/exec/obidos/ASIN/3527717471/willemersinfo-21 [2] http://www.willemer.de/informatik/cpp/
Johannes S. schrieb: > Flugzeuggröße könnte man Anhand von Eigenschaften wie Spannweite oder > Passagierzahl festmachen. Ja, klar, das meinte ich ja: Du bietest ja auch schon zwei Möglichkeiten an, und mir würden da noch Höhe, Rumpflänge, umbauter Raum, Gewicht, Zuladung, etc. einfallen... nur Moby weiß, wie so ein allgemeingültiger Vergleich aussehen muß... oder so. ;-) > Aber sowas muss intuitiv sein, überladene > Operatoren soll man nicht einfach einsetzen nur weil man es kann. > Trotzdem macht sowas Sinn weil zb generische Listen dann Objekte nach > Größe sortieren können. Ja, natürlich. Die Möglichkeiten von -- nicht nur, aber auch -- C++ sind sehr mächtig, aber wie alle mächtigen Werkzeuge muß man sie mit Bedacht einsetzen. Aber selbst wenn man seine Funktionen nur an seine Datenobjekte bindet, ist das schon ein eindeutiger Fall von OOP -- selbst wenn das zB. in C geschieht... ;-)
Sheeva P. schrieb: > Ja, klar, das meinte ich ja: Du bietest ja auch schon zwei Möglichkeiten > an, und mir würden da noch Höhe, Rumpflänge, umbauter Raum, Gewicht, > Zuladung, etc. einfallen... ... sicher nicht auf Mikrocontrollern. Bitte mal das Eingangs-Posting beachten und bei der Sache bleiben.
Beitrag #6232125 wurde vom Autor gelöscht.
Beitrag #6232126 wurde vom Autor gelöscht.
M.C. schrieb: > Sheeva P. schrieb: >> Ja, klar, das meinte ich ja: Du bietest ja auch schon zwei Möglichkeiten >> an, und mir würden da noch Höhe, Rumpflänge, umbauter Raum, Gewicht, >> Zuladung, etc. einfallen... > > ... sicher nicht auf Mikrocontrollern. Aber ja doch, warum denn nicht? Man kann das sogar wunderbar kombinieren, sogar mit Fuzzy Logic auf einer winzigen 16-Bit-MCU wie dem Motorola 68HC12. Wirklich schade, daß Du so wenig Ahnung hast. ;-) > Bitte mal das Eingangs-Posting beachten und bei der Sache bleiben. Bitte mal was zur Sache beitragen.
Sheeva P. schrieb: > Bitte mal was zur Sache beitragen. Wirklich schade wenn man vor lauter missionarischer OOP Verblendung nicht mehr erkennt was Sache ist :(
M.C. schrieb: > wenn man vor lauter missionarischer OOP Verblendung Wer ist hier "Verblendet"? Mir ist es doch scheißegal, welche Sprache du nutzt. Du bist hier der Priester, welche die OOP madig machen will. Warum? Was ist dein Ziel? Nenne dein Motiv!
Johannes S. schrieb: > [...] Sowas muss intuitiv sein, überladene > Operatoren soll man nicht einfach einsetzen nur weil man es kann. Genau so! Bei einem Flugzeug würde ich das definitiv nicht machen. Ich würde stattdessen sowas schreiben
1 | struct Flugzeug { |
2 | double spannweite; |
3 | double gewicht; |
4 | |
5 | struct SpannweiteComperator { |
6 | bool operator()(const Flugzeug &a, const Flugzeug &b) const noexcept { |
7 | return a.spannweite < b.spannweite; |
8 | }
|
9 | }
|
10 | |
11 | struct GewichtComperator { |
12 | bool operator()(const Flugzeug &a, const Flugzeug &b) const noexcept { |
13 | return a.gewicht < b.gewicht; |
14 | }
|
15 | }
|
16 | }
|
17 | |
18 | template<class T, class COMP = std::less<T>> |
19 | const T& max(const T& a, const T& b, const COMP &comp = COMP()) { |
20 | return (comp(a, b)) ? b : a; |
21 | }
|
22 | |
23 | int main() { |
24 | Flugzeug a; |
25 | Flugzeug b; |
26 | |
27 | // ...
|
28 | |
29 | Flugzeug c = max(a, b, Flugzeug::SpannweiteComperator()); |
30 | }
|
Ungetestet! Und zugegebenermassen, für diesen Einsatz unnötig kompliziert. Aber man kann die Komperatoren auch für sortierte Container wie std::set oder std::map nutzen. Dann wird es erst interessant!
Hallo, Sheeva P. schrieb: > Von jüngeren Kollegen habe ich allerdings gehört.. Vielen Dank, das werde ich mir auf jeden Fall mal ansehen. rhf
Hallo, Zombie schrieb: > Genau so! Bei einem Flugzeug würde ich das definitiv nicht machen. Der von mir ins Spiel gebrachte Flugzeugvergleich war nur als Beispiel gedacht, um eine Erklärung zu erhalten wie der Compiler bei der Anwendung von Templates entsprechenden Code erzeugt, wenn es um Objekte geht, die nicht so offensichtlich vergleichbar sind wie z.B. Zahlen. Das das gewählte Vergleichsbeispiel ziemlich unsinnig ist, ist (selbst mir als OOP-Unkundiger) völlig klar. rhf
Roland F. schrieb: > um eine Erklärung zu erhalten wie der Compiler bei der > Anwendung von Templates entsprechenden Code erzeugt, Ein interessanter Aspekt, die Codegeneratoren. Das jonglieren mit Datentypen halte ich für noch viel interessanter, als die Codegenerierung.
Zombie schrieb: > Und zugegebenermassen, für diesen Einsatz unnötig > kompliziert. Ein klassisches OOP Merkmal an den meisten Einsatzorten der MC-Programmierung! Arduino Fanboy D. schrieb: > Warum? > Was ist dein Ziel? > Nenne dein Motiv! Setze Dich doch bitte endlich mal mit den von mir gebrachten Beispielen für Kosten und Auswirkungen dieser komplexen (beschönigend: mächtigen) Programmiertechniken auseinander statt ewig hilflos im Nebel angenommener böser Motive herumzustochern. Fällt Dir das schwer? Weil das vielleicht nicht immer rein technisch erklärt werden kann? Weil wir hier von einem Denk Werkzeug und nicht etwa von einem Hammer oder einer CNC Maschine sprechen?
M.C. schrieb: > Setze Dich doch bitte endlich mal mit den von mir gebrachten Beispielen Du hast ein konkretes Beispiel genannt? Wo?
Arduino Fanboy D. schrieb: > Du hast ein konkretes Beispiel genannt? > Wo? Ich stelle fest: Du bist einfach unfähig oder unwillig. Zu lesen, wahrzunehmen, über den technischen Tellerrand hinauszuschauen. Entschuldigung. Ein Hardcore-Scheuklappenträger. Denen ist ob ihrer Betriebsblindheit schwer zu helfen. Um Dir auf die Sprünge zu helfen, ich rede nicht von Code-Beispielen! Immerhin bemühst Du Dich auf Deinem Spezial-Gebiet zu helfen. Das möchte ich ausdrücklich anerkennen. Den meisten dürfte das aber kaum überzeugend zum Einstieg verhelfen. Liegt in der Natur der Sache (zumindest bei den Mikrocontrollern).
Also kein konkretes Beispiel. Welche Motive verfolgst du? PS: Du hast schon bemerkt, dass du am zeigen eines einfachen, nachprüfbaren, Beispiels jämmerlich versagt hast......
M.C. schrieb: > ich rede nicht von Code-Beispielen! Irgendwas nachprüfbares, würde ja schon reichen.... Irgendwas.... Merke: Behauptungen, ohne Nachweis, sind wertlos bis irreführend. Dutzende solcher Behauptungen hast du bisher abgelassen. Welche Motive verfolgst du?
Arduino Fanboy D. schrieb: > > Welche Motive verfolgst du? Na welche schon. Bestimmt nicht über das Thema diskutieren, sondern eher den eigenen Horizont zu demonstrieren. Man muß sich da einfach durchringen diese "Mit"streiter zu ignorieren. Manchmal ergeben sich auch interessante Diskussionen in anderen Threads, wenn diese sich am Honigtopf laben.
Carl D. schrieb: > Man muß sich da einfach > durchringen diese "Mit"streiter zu ignorieren. Was weder Dir noch anderen gelingt. Fragt Euch doch mal warum :) Wie die Katzen schleichen gewisse Missionare um den heißen Brei bösartiger "Behauptungen"...
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.