Funktionszeiger im struct in C

Wenn du die Instanz wie oben anlegst, wird die Funktionsadresse vom 
Compiler zur Compilezeit in die Struktur eingetragen. Wo genau ist das 
Problem?

holzmagnet wrote:
> hi
>

1

> #include "uart.h"

2

> 

3

> extern struct

4

> {

5

>    char buffer[10] = "         ";

6

>    VoidFnct send = uart_send;

7

> }uart;

8

> 

9

> void uart_send(char [] to_send)

10

> {

11

>     // TODO senderoutine

12

> }

13

>

>
> das könnte evtl. weiterhelfen. Mit extern machst du die Sache
> öffentlich. Kanns aber leider net testen. Probiers ma aus.

Das dürfte eigentlich nicht funktionieren. In dem Moment
in dem da eine Initialisierung ist, ist das Ganze eine Definition
und keine Deklaration mehr (das extern wird in dem Fall quasi
ignoriert). Das einzige was einen dann noch rettet, ist das
Ignorieren der 'One Definition Rule' im gcc-Linker.

Im Übrigen schliesse ich mich sous bzw. Sven an.
Es macht nicht wirklich Sinn, objektorientierte Konzepte aus
C++ 1:1 nach C übernehmen zu wollen. In C hast du nun mal das
Gegenstück zu einem Konstruktor nicht. Eine Initialisierung ist
da nur ein müder Ersatz dafür.

> Ich habe da noch ein Posting im Kopf,
> in dem es hiess dass ein grosser Overhead erzeugt wird

Nicht wirklich. Kommt immer darauf an, was man aus C++ benutzt.
Letztendlich implementiert ein C++ Compiler das von dir gewünschte
Verhalten (virtuelle Funktionen) auch nicht anders, nur macht er
es ein bischen cleverer, indem nicht jedes Objekt eine Tabelle
von Funktionszeigern beeinhaltet, sondern dafür eine eigene
Struktur abgestellt wird und im Objekt ein Pointer auf eben diese
Funktionspointertabelle abgelegt wird.

Die vernünftigste Lösung ist immer noch ein Mittelweg und die
Forderung nach Initialisierung der Funktionspointer über Bord
zu schmeissen. Da macht man sich dann eine Init Funktion, in der
die Funktionspointer rein kommen und die für jedes Objekt auf-
gerufen werden muss.

*Wenn man denn unbedingt 'objektorientiert' in C arbeiten will*
*und die object.function Notation haben möchte.*

Ob das so Sinn macht steht auf einem anderen Blatt. Speichertechnisch
ist das ein ziemlicher Horror, solange die Funktionspointer nicht
ihre wirkliche Stärke zur Implementierung von virtuellen Funktionen
ausspielen können.

> Im Übrigen schliesse ich mich sous bzw. Sven an.

Dito. Aber als Schnellschuss bzw. der Neugier wegen, würde ich mal 
folgenden Aufbau testen:

uart.c
======

#include "uart.h"

suart uart = { "         ", uart_send };

void uart_send(char [] to_send)
{
    // TODO senderoutine
}



uart.h
======

#ifndef UART_H
#define UART_H

#include "common.h"

typedef void (*VoidFnct)( char [] );

typedef struct
{
   char buffer[10];
   VoidFnct send;
} suart;

extern suart uart; // in uart.c

#endif



main.c
======

#include "common.h"
#include "uart.h"

int main (void)
{
  uart.send("hello");
  while(1);
}



common.h
========

#ifndef COMMON_H
#define COMMON_H

#include <avr/io.h>

#endif

NoIdea wrote:

> der Fkt.-pointer ist in den allermeisten Fällen nicht wirklich von
> Nöten. War nur ne Idee (keine gute aber immerhin ;) ).

Ne. ist doch ok.

Wenn die Memberfunktionen keine virtuellen Funktionen sind,
dann verändert ein C++ Compiler intern (*) einen Aufruf

   object.function( argument );

zu

  function( object, argument );

macht also auch einen stink normalen Funktionsaufruf daraus, bei
dem als erstes Argument (oder letztes, je nach Compiler) das
Objekt selbst übergeben wird (als Referenz).

Diese . Notation ist also im Grunde für einen C++ Compiler nur
'syntactic sugar' um eine andere Syntax für einen Member-
Funktionsaufruf zu haben, der ein bischen schöner aussieht und
Aufrufe von Memberfunktionen von Aufrufen von standalone
Funktionen zu unterscheiden.

(*) Das ist ihm vom C++ Standard natürlich nicht so vorgeschrieben,
aber seit Stroustroups Zeiten wird das so gemacht. Daher auch
unter anderem das viel gepriesene und noch viel öfter verfluchte
Name-Mangling von Member-Funktionsnamen.