Hallo Stefan,
es geht nicht um die Nachbildung einer OOP-Funktionalität. Sast schrieb was von
und eine OOP-Denke kann hierbei vom Vorteil sein, muss aber nicht.
Ich sehe den Vorteil von Funktionspointern in der Flexibilität die ich dadurch bekomme, es geht mir nicht um Pseudo-OOP. Vielmehr kann ich so unterschiedliche Funktionen (respektive Verhalten) einem Struct zuordnen (z.B. wann was wie schalten soll..)
Um bei dem LED-Beispiel zu bleiben: Eine LED soll schalten, wenn ein Signal an einem Pin anliegt, die andere soll bei dem Erreichen eines bestimmten ADC-Wert ausgehen. Dafür kann ich einen Funktionspointer mit einer "Aus/An"-Funktion und einen anderen mit "Bedingung erfüllt?"-Funktion verwenden, zudem könnte ich dem Controller über eine Serielle-Verbindung sagen "Wenn der Pin so ist, dann mach mit dem Pin mal das...".
Es mag dir nicht darum gehen, aber das ändert nichts daran, dass es nun mal Pseudo-OOP ist.
Deine Struct mit den Funktionspointern darin ist nichts anderes als eine Klasse mit virtuellen Methoden. Dann erzeugst du für die LEDs einzelne Instanzen der Struct wobei die Funktionspointer auf unterschiedliche Funktionen zeigen. Das ist wiederum nichts anderes, als konkrete Klassen von der virtuellen Basisklasse abzuleiten, die die virtuellen Methoden unterschiedlich implementieren.
Davon abgesehen geht das, was sast schrieb (und an den ging mein Kommentar schließlich) noch viel eindeutiger in Richtung OOP (Kapselung, Konstruktor, etc).
Und meine Meinung dazu ist eben:
Wenn man OOP machen will und eine OO-Sprache zur Verfügung steht, dann finde ich es nicht sinnvoll, sich dafür zu entscheiden, die OOP in der nicht-OO-Spache nachzubilden. Das ist ein bisschen so, als würde man einen Nagel mit der Wasserpumpenzange in die Wand schlagen (was auch irgendwie geht) weil man diese gerade in der Hand hatte, obwohl doch ein richtig schöner Hammer in Griffweite gelegen hat.
MfG
Stefan
Es ist natürlich richtig, dass man eine Programmiersprache nicht verbiegen muss, um eine andere nachzubilden. Aber es ist doch auch nicht falsch die Möglichkeiten einer Sprache zu nutzen. Und ein struct ist im Prinzip die Urform der Klasse. So sehe ich das jedenfalls. Zur OOP gehört noch ein bisschen mehr als nur alles in ein struct zu bündeln.
Wenn schon ein Gleichnis herhalten muss, dann sind das wohl beides Hämmer. Der eine hat nur einen ergonomischen Griff und ist bunt und der andere ist einfach nur ein Hammer mit geradem Stiel. Und wenn man ihn nun auch etwas bunt macht, ist es trotzdem immer noch ein Hammer.
Ich weise gern darauf hin, dass ein struct nicht nur eine Ansammlung von Variablen sein muss. Und ich werde mich auch weiterhin nicht dafür schähmen, dass ich das auch kund tue.
Und die Wortwahl in Richtung Kapselung und Konstruktoren war durchaus absichtlich gewählt, um genau auf diese Ähnlichkeiten hinzudeuten.
PS: Ich bin davon ausgegangen, dass der C++ Hammer eine Klaue hat.
sast
雅思特史特芬
开发及研究
Erstmal vielen lieben Dank an alle die sich hier beteiligt und geholfen haben
Ich muss sagen, dass war ein echt netter Einstand
Zur Abschließenden Debatte: http://www.fullduplex.org/humor/2006...ming-language/
(Mein Favorit davon ist APL)
Wer sich von Euch schon einmal mit einem USB-ISP von Diamex geärgert hat kann gerne hier rein schauen: https://www.roboternetz.de/community...tioniert-nicht
Viele Grüße,
Crazy
Lesezeichen