DDR und PORT in einem Struct

[oberallgeier]

...
#define Led_2_An() SetBit(PORTA,PA1)
...

Dazu ne Anmerkung bzw. meine Überlegungen. Einige meiner #defines habe ich ohne Klammern für die Parameterliste geschrieben, siehe oben - einfach um diese von Funktionsaufrufen deutlich zu unterscheiden. Sprich (siehe oben)
#define Taste1_an .. IsBitClr (PrtTAST, Tst_1) ........ statt
#define Taste1_an () IsBitClr (PrtTAST, Tst_1) ......,
bzw. in Deinem Fall würde ich schreiben
Led_2_An ...... statt
Led_2_An () ...... .

Für mich macht das Sinn wegen der besseren Lesbarkeit, da diese Schreibweise deutlich den Unterschied zum Funktionsaufruf mit leerer Parameterliste zeigt. Und der Compiler meckert es nicht an. Wie weit ein Profi das gut findet, weiß ich aber nicht.

Vielleicht kannst Du später auch Deine struct-Geschichte nach Erprobung vorstellen?

[CrazyMetal]

Hi oberallgeier,
schau dir das mal an:

#define SetBit(ADDR,BIT) (ADDR |= (1<<BIT))

#define WasBinIch_1 42
#define WasBinIch_2 SetBit(PORTA,PA0)
#define WasBinIch_3() SetBit(PORTA,PA1)


void main()
{
	int x = WasBinIch_1;	// Hier ist klar, das du eine Variable/einen Wert verwendest
	WasBinIch_3();		// Hier ist klar, dass was passiert (es sieht wie ein Funktionsaufruf aus)
	
	WasBinIch_2;	// Was ist das?
			// Geh' mal von einem Programm aus wo du grade in Zeile 1580
			// ließt und nicht das #define-Statement im Blick hast ... ;-)
}

In der stdio.h findest du unteranderem diese Zeile:
"#define getchar() fgetc(stdin)", vermutlich aus den selben Gründen wie oben.

[EDIT] Kleiner Nachtrag: IBM schreibt hierzu: "An empty formal parameter list is legal: such a macro can be used to simulate a function that takes no arguments." http://publib.boulder.ibm.com/infoce...rc09cpxmac.htm

Wenn ich Zeit habe, bastel ich mal ein kleines Beispiel wie ich das mit den Structs meinte

-Crazy

[sast]

Auch wenn der Thread schon geschlossen ist.

Nur mal so als Anregung zum struct. Wenn du das konsequent durchziehen möchtest, wäre es von der Lesbarkeit doch sicher noch besser, wenn du init oder zB Zustandsänderungen auch gleich als Funktionen im struct ablegst.
Ein Aufruf led1.init oder led1.switch(1), led1.switch(0) sollte fürs OOP Verständnis nachvollziehbar sein. Vielleicht kapselst du die Variablen für Port Pin usw auch und baust ein create dazu. Bin mal auf dein Beispiel gespannt.

sast (der findet, dass structs unterschätzt werden)

[CrazyMetal]

Nur mal so als Anregung zum struct. Wenn du das konsequent durchziehen möchtest,
wäre es von der Lesbarkeit doch sicher noch besser, wenn du init oder zB
Zustandsänderungen auch gleich als Funktionen im struct ablegst.

Jepp, genau das hatte ich geplan. Der Code ist plakativ, damit Funktionspointer nicht unnötig das Beispiel aufblähen.

sast (der findet, dass structs unterschätzt werden)

Könnte man hier voten: +1

[sternst]

Nur mal so als Anregung zum struct. Wenn du das konsequent durchziehen möchtest, wäre es von der Lesbarkeit doch sicher noch besser, wenn du init oder zB Zustandsänderungen auch gleich als Funktionen im struct ablegst.
Ein Aufruf led1.init oder led1.switch(1), led1.switch(0) sollte fürs OOP Verständnis nachvollziehbar sein. Vielleicht kapselst du die Variablen für Port Pin usw auch und baust ein create dazu.

Ich finde es einigermaßen sinnfrei, OOP in C "nachzumachen", wenn man statt dessen auch gleich eine richtige OO-Sprache verwenden könnte, z.B. C++.

[CrazyMetal]

Hallo Stefan,

Ich finde es einigermaßen sinnfrei, OOP in C "nachzumachen", wenn man statt dessen auch gleich eine richtige OO-Sprache verwenden könnte, z.B. C++.

es geht nicht um die Nachbildung einer OOP-Funktionalität. Sast schrieb was von

(...) sollte fürs OOP Verständnis nachvollziehbar sein.

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...".

[sternst]

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..)

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.

[CrazyMetal]

Davon abgesehen geht das, was sast schrieb (und an den ging mein Kommentar schließlich)

Hab nix gesagt

als würde man einen Nagel mit der Wasserpumpenzange in die Wand schlagen (...) obwohl doch ein richtig schöner Hammer in Griffweite gelegen hat.

Nun ja, aber damit kannst du ihn nicht gleich wieder raus ziehen.

Viele Grüße,
Crazy

[sternst]

Nun ja, aber damit kannst du ihn nicht gleich wieder raus ziehen.

Oh, hatte ich etwa vergessen zu erwähnen, dass das ein Hammer mit Klaue war?

[sast]

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