Übergabe Funktionspointer und Struct

[Martin J. (bluematrix)]

Hallo,

ich möchte eine Bibliothek möglichst variabel gestalten und komme dabei 
an meine Grenzen in der Programmierung.

Speziell möchte ich verschiedene Displaytreiber an eine übergeordnete 
Grafik-Bibliothek übergeben, da ich 3 Grafik-Displays (2 verschiedene 
Typen) an einen Controller anschließen muss.

Der Treiber für die Displays ist so Aufgebaut, dass immer ein Struct mit 
allen Informationen übergeben wird.

typedef struct xxx_data_t  {
  uint8_t      pin_cs;
  uint8_t      pin_rs;
  uint8_t      pin_dc;
  PORT_t      *port;
  SPI_Master_t  *spi;
}xxx_data_t;

// BSP
ili9341_setPixel(&ili9341_1, 123, 240); // zeichne Pixel

Jetzt möchte ich zum Beispiel mit meiner Grafikbibliothek etwas 
zeichnen, Dazu muss ich den Funktionspointer und das Struct mit den 
Schnittstellen Infos übergeben.

void grafiklib(fctptr, struct)
{
    // mach etwas
    fctptr(struct, 123, 240);
}

Mein Problem ist, dass ich verschiedene Displaytreiber mit der Grafiklib 
verwenden möchte (ili9341, S65, Nokia, ...). Die Grafikfunktionen der 
Treiber sind immer gleich. Wie kann ich das in C realisieren, denn ich 
kann ja der Funktion "void grafiklib(fctptr, struct)" nicht verschiedene 
typen (structs) übergeben.
... oder wie kann ich das anders aufbauen.


Ich hoffe mein Problem ist so einigermaßen klar geworden.

[Klaus W. (mfgkw)]

Martin J. schrieb:
> Ich hoffe mein Problem ist so einigermaßen klar geworden.

Sorry, mir leider nicht.

Das fctptr im obigen Beispiel ist was? Eine Funktion von einem fremden 
Treiber, den du nur übernimmst?

[Johann L. (gjlayde)]

1) Origanisiere die Daten für die verschiedenen Treiber so, dass sie 
alle das gleiche Layout haben.  Evtl. ist dann Info in den Daten die ein 
Treiber nicht braucht.

oder

2) Lege die Strukturen in eine Union.  Jede Struktur und die Union haben 
als erstes Element ein Datum, dass die Daten identifiziert:
 

typedef union
{
    int id;

    struct
    {
        int id;
        ...
    } foo;
    struct
    {
        int id;
        ...
    } bar;
    ...
} data_t;

void f (data_t *data)
{
    if (data->id == DATA_FOO)
    {
        // use data->foo
    }
}

oder

3) Nimm einen void* und caste zu dem Datenzeiger der gebraucht wird 
(nicht so toll).

[Klaus W. (mfgkw)]

Ich glaube, mir dämmert dein Problem.

Die struct soll sich von Treiber zu Treiber irgendwie unterscheiden, 
trotzdem willst du sie über dieselbe Parameterliste bringen, und 
letztlich landet sie pber den Funktionspointer als Parameter bei der 
richtigen Funktion?

Dann wäre evtl. eine union der richtige Weg:
Du schreibst für jeden Treiber die struct, machst von allen eine union 
und übergibst jeweils den Funktionszeiger und einen Zeiger auf die 
union.
Die Funktion nimmt sich dann aus der union das, was sie braucht.

[Programmierer (Gast)]

Das ist der Anwendungsfall für C++ und virtuelle Funktionen. 
Einfacher, kürzer, fehlersicherer, und effizienter als die C-Wurstelei 
mit Funktionspointern.

class DisplayDriver {
  public:
    virtual void setPixel (int x, int y, int color) = 0;
    /* hier weitere Funktionen die jedes Display unterstützen muss, zB Bereiche ausmalen, ein/aus schalten etc. */
};

class Driverili9341 : public DisplayDriver {
  public:
    virtual void setPixel (int x, int y, int color) {
      /* .. display-spezifisches Pixelsetzen */
    }
    /* Hier o.g. weitere Funktionen unterbringen */
    
    /* Hier displayspezifische Variablen unterbringen, die sonst in das struct kommen würden */
    uint8_t      pin_cs;
    uint8_t      pin_rs;
    uint8_t      pin_dc;
    PORT_t      *port;
    SPI_Master_t  *spi;
};

// Funktion der GrafikLib die mit beliebigen Display-Typen funktioniert.
void grafikLib_drawText (DisplayDriver& display, int x, int y, const char* text) {
  // Render-Algorithmus ...
  
  // Ein gerendertes Pixel setzen. Hier wird automatisch die richtige Funktion der abgeleiteten Klasse, im Beispiel Driverili9341, aufgerufen.
  display.setPixel (x, y, 42);
}

int main () {
  // Einen bestimmten Display-Treiber anlegen
  Driverili9341 display;
  // Die allgemeine Text-Render-Funktion auf dieses spezielle Display anwenden
  grafikLib_drawText (&display);
}

[Klaus W. (mfgkw)]

Programmierer schrieb:
> Das ist der Anwendungsfall für C++

ja, aber Masochismus ist verbreitet, das muß man akzeoptieren :-)

[Programmierer (Gast)]

Klaus Wachtler schrieb:
> ja, aber Masochismus ist verbreitet, das muß man akzeoptieren :-)
Ich lasse mir zwar auch gerne den Hintern versohlen, aber so schlimm 
dass ich so etwas in C machen würde ist es noch nicht!

[Markus F. (mfro)]

Nehmen wir an, Du hast folgende "Treiberfunktionen":

void init_driver1(void);
void init_driver2(void);
void exit_driver1(void);
void exit_driver2(void);
void draw_line_driver1(int x, int y, int x2, int y2);
void draw_line_driver2(int x, int y, int x2, int y2);

Dann bastelst Du dir ein struct, daß die Funktionszeiger aufnehmen kann:

struct driver_entry
{
    void (*init)();
    void (*exit)();
    void (*draw_line)(int x, int y, int x1, int x2);
    /* ... */
};

...und initialisierst ein Array aus solchen structs, über das Du 
zugreifen kannst:

static struct driver_entry drivers[] =
{
    { 
        init_driver1,
        exit_driver1,
        draw_line_driver1,
    },
    {
        init_driver2,
        exit_driver2,
        draw_line_driver2,
    }
};
static int num_drivers = sizeof(drivers) / sizeof(driver_entry);

Jetzt kannst Du nach Belieben damit rumhantieren:

int main(void)
{
    struct driver_entry *my_driver = &drivers[1]; /* nehmen wir mal den */

    my_driver->init();
    my_driver->draw_line(0, 0, 10, 10);
    my_driver->exit();
}

Sooo viel schöner ist das in C++ auch nicht. Und wenn die 
unterschiedlichen "Treiber" unterschiedliche Funktionen brauchen, muß 
man halt noch eine union dazwischen hängen.

[Programmierer (Gast)]

Markus F. schrieb:
> Und wenn die
> unterschiedlichen "Treiber" unterschiedliche Funktionen brauchen, muß
> man halt noch eine union dazwischen hängen.
Und wenn ein Treiber viel mehr Speicher braucht als die anderen, muss 
man für jeden anderen genauso viel Speicher verschwenden, da ein union 
immer mindestens so groß ist wie das größte Element...

Markus F. schrieb:
> Sooo viel schöner ist das in C++ auch nicht.
Immerhin muss man die vtable (dein drivers array) nicht von Hand 
anlegen. Wenn man mehrere ähnliche Treiber hat, kann man eine abstrakte 
Zwischen-Klasse anlegen, und dann spart man erst Recht Tipparbeit, und 
geht einer größeren Fehlerquelle aus dem Weg... Warum auf den Komfort 
verzichten? Warum wollen immer alle um jeden Preis C++ vermeiden, auch 
wenn es perfekt geeignet ist?

[Markus F. (mfro)]

Programmierer schrieb:
> Warum wollen immer alle um jeden Preis C++ vermeiden, auch
> wenn es perfekt geeignet ist?

Ich hätte das (möglicherweise) tatsächlich mit C++ gemacht. 
Möglicherweise sogar obwohl Libraries mit C++ manchmal überhaupt 
keinen Spaß machen...

Der Fragesteller hat aber offensichtlich mit C schon seine Probleme, 
warum ihm also 'nen Daimler aufschwatzen, wenn er eigentlich ein Fahrrad 
wollte? ;)

[Programmierer (Gast)]

Markus F. schrieb:
> Ich hätte das (möglicherweise) tatsächlich mit C++ gemacht.
> Möglicherweise sogar obwohl Libraries mit C++ manchmal überhaupt
> keinen Spaß machen...
Man kann in jeder Sprache Murks produzieren...
> Der Fragesteller hat aber offensichtlich mit C schon seine Probleme,
> warum ihm also 'nen Daimler aufschwatzen, wenn er eigentlich ein Fahrrad
> wollte? ;)
Vielleicht weil er damit schneller und bequemer über die Alpen kommt...

[Martin J. (bluematrix)]

Klaus Wachtler schrieb:
> Ich glaube, mir dämmert dein Problem.

Genau :-)


Allen schon mal vielen Dank für die Ideen. Ja man könnte das auch schön
elegant in C++ realisieren, doch dann müsste ich meine ganzen anderen
Bibliotheken ändern und darauf habe ich grad keine Lust. ;-)
Am Ende ist die Verwendung der Structs für die Variable
SPI-Schnittstelle der Treiber ja auch nur ein Pseudo C++, so dass man
weiter C verwenden kann.

Ich hatte nur gedacht, dass es für solche Fälle noch andere
Möglichkeiten in C gibt. Immerhin wurden auch sehr Komplexe Programe in
C geschrieben, die eine ähnliche Flexibilität erfordern.

Danke.

[Markus F. (mfro)]

... dann machen wir die vtable eben vollends fertig:

extern void text_init(void);
extern void text_exit(void);
extern void text_print(int x, int y, char *txt);
extern void graf_init(void);
extern void graf_exit(void);
extern void draw_line(int x, int y, int x1, int y1);

enum driver_type
{
    GRAPHICS_DRIVER,
    TEXT_DRIVER
};

struct graphics_driver
{
    void (*init)();
    void (*exit)();
    void (*draw_line)(int x, int y, int x1, int x2);
    /* ... */
};

struct char_driver
{
    void (*init)();
    void (*exit)();
    void (*print)(int x, int y, char *txt);
};

static struct graphics_driver driver1 =
{
    .init = graf_init,
    .exit = graf_exit,
    .draw_line = draw_line,
};

static struct char_driver driver2 =
{
    .init = text_init,
    .exit = text_exit,
    .print = text_print,
};

struct driver
{
    enum driver_type type;
    union
    {
        struct graphics_driver *gd;
        struct char_driver *cd;
    };
};

struct driver drivers[] =
{
    { .type = GRAPHICS_DRIVER, { .gd = &driver1 }},
    { .type = TEXT_DRIVER, { .cd = &driver2 }},
};

Nicht unbedingt schön, aber tun tut's ;)

[Programmierer (Gast)]

Martin J. schrieb:
> doch dann müsste ich meine ganzen anderen
> Bibliotheken ändern und darauf habe ich grad keine Lust. ;-)
Was musst du denn da alles ändern? Hast du 1000x die Bezeichner "this" 
und "class" verwendet? Die paar fehlenden void* -> T* casts findet der 
Compiler und sie sind schnell behoben. Außerdem spricht auch nichts 
dagegen, den Rest als C zu kompilieren...

[Amateur (Gast)]

Funktionszeiger gibt es seit Anno Tobak.

Wenn Du sowieso eine Struktur initialisierst, spendiere ihr doch dabei 
gleich die passende Funktion.

Leider ist das "Steinzeit-C".


Virtuelle Funktionen gibt es zwar nicht ganz so lange (C++), aber 
manchmal hilft es eine Pupille ins nächst verfügbare C-Buch zu 
schmeißen.
Ist ganz einfach; beiß nicht.

Es gibt wohl kaum Lehrbücher, in denen gerade am Beispiel von grafischen 
Ausgaben, diese Mechanismen nicht erläutert werden. Da wird zwar oft 
eine virtuelle Funktion mit Namen print verwendet, mit der dann ein 
Etwas (Punkt, Kreis, Linie usw.) ausgegeben wird, das Prinzip ist aber 
übertragbar.