www.mikrocontroller.net

Forum: Compiler & IDEs cast Zeiger auf Methode -> Zeiger auf Funktion


Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich bearbeite ein Projekt mit C-Bibliotheken/APIs und C++ Anwendung.
Dabei habe ich das Problem, dass ich eine C-Funktion benutzen möchte,
die als Parameter u.a. einen Funktionspointer vom Typ void (*)(long)
hat. Dieser C-Funktion möchte ich nun als Parameter einen Pointer auf
eine Klassenmethode vom Typ void (myclass::*)(long) mitgeben. Leider
habe ich bisher keinen Weg gefunden, den Typ anzupassen. Ich alle
möglichen Casts (reinterpret_cast usw.) probiert, aber es geht nicht.
Kennt jemand einen Hack?
Danke!
Tom

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wüsste nicht, wie eine C-Funktion auf Elemente von C++-
Klassen zugreifen können sollte -- und das müsste sie ja in
diesem Fall.

Du kannst nur einen generischen Zeiger durchreichen (als void *),
der dann irgendwie wieder in einem C++-Code landet, der ihn
entsprechend seiner tatsächlichen Klasse interpretiert.

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal die sauberste Variante wäre der Einsatz einer
Stub-Funktion. Ähnlich folgendem Beispiel:

[C]

void deine_Funktion(void* funcPtr)
{
   //...
}

void stubFunc(long arg)
{
   classType yourClass; // kann auch ein globales Klassenobjekt sein

   yourClass.classFunc(arg);
}

[\C]

Den FunktionsPointer auf die Stub-Funktion kannst Du dann deiner
Funktion übergeben.

Ich denke mal das ist das, was Jörg meinte.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht nicht. Ein Zeiger auf eine Memberfunktion und einer auf eine
normale Funktion sind nicht kompatibel. Das geht ja schon alleine
deshalb nicht, weil eine Memberfunktion automatisch noch den
this-Zeiger implizit übergeben bekommt. Meistens ist ein
Memberfunktionszeiger sogar ganz anders aufgebaut (es werden
extra-Informationen mit abgespeichert), als ein normaler
Funktionszeiger. Eine Konvertierung ist normalerwerise nicht möglich.
Auch zwischen void* und Funktionszeigern oder void* und
Memberfunktionszeigern ist zumindest laut C++-Norm eine Konvertierung
nicht möglich (die meisten Compiler lassen erstere aber meistens doch
zu).
Kannst du den Code nicht in eine Nichtmemberfunktion schreiben, die
extern "C" ist? Oft haben diese Callback-Mechanismen die Möglichkeit,
einen void*-Parameter zu hinterlegen, der beim Aufruf der Funktion
übergeben wird. Dort könntest du dann einen Zeiger auf dein Objekt
übergeben, über den deine Callback-Funktion dann die Memberfunktion
aufruft.

PS: g++-spezifisch gibt's noch:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Bound-...
Aber das sollte nur verwendet werden, wenn es wirklich und mit
Sicherheit absolut keinen anderen Weg gibt.

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg
Danke für die schnelle Antwort. Ich befürchte Du hast Recht.

Ich habe gerade einen Versuch mit void* als "Zwischenstation"
gemacht. Selbst der Cast von void (myclass::*)(long) nach void* geht
nicht.
Ich sollte mir lieber eine andere Implementierung ausdenken.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der übliche Weg ist der, den Karsten aufgezeigt hat.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn deine C-Funktion noch einen zusätzlichen void* Parameter
neben dem Funktionszeiger akzeptiert, der dann an die Callback-
Funktion weitergegeben wird, dann kannst du das
ganze so machen.


void CallbackStubForMyClass( void* Arg )
{
  ((MyClass*)Arg)->Callback();
}

class MyClass
{
  ...

  public void foo()
  {
    SomeFunction( CallbackStubForMyClass, this );
    /*  SomeFunction ruft dann über den Funktionszeiger
        die Funktion CallbackStubForMyClass auf, die
        ihrerseits dann die Member Funktion aufruft */

  }

  public void Callback()
  {
    /* letztendlich landet der Call dann hier */
  }
};

Das geht aber nur deshalb, weil die Funktion SomeFunction
2 Pointer akzeptiert und es auf diese Art möglich wird, den
this Pointer soweit durchzuschleifen, dass der CallbackStub
ihn benutzen kann um darauf eine Member Funktion aufzurufen.

Wenn dir SomeFunction aufs Aug gedrückt wurde und es keine
Möglichkeit gibt, den this Pointer durchzuschleifen, dann bleibt
nichts anderes üblich, als eine globale Pointer Variable zu
benutzen, die diese Aufgabe übernimmt:

MyClass* pCallbackObj;

void CallbackStubForMyClass()
{
  pCallbackObj->Callback();
}

class MyClass
{
  ...

  public void foo()
  {
    pCallbackObj = this;
    SomeFunction( CallbackStubForMyClass );
  }

  public void Callback()
  {
    /* letztendlich landet der Call dann hier */
  }
};

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@all
vielen Dank für die rege Anteilnahme an meinem Problem!

Ich glaube, ich muss ein bisschen mehr zu meinem Problem erklären.
Ich schreibe eine Anwendung für einem ARM9 und habe dazu ein RTOS
(ThreadX)als C-Bibliotheken (keine Sourcen) gegen die ich meine
Anwendung linke.
Ich habe mir eine Klasse thread geschrieben, die die C-Funktionen zur
Threadhandhabung kappselt. Objekte die in einem eigenen Thread laufen
sollen, werden von thread abgeleitet. Die Klasse enthält eine virtuelle
Methode execute, die den Code enthält, der in dem Thread ausgeführt
werden soll. execute wird in den abgeleiteten Klassen implementiert.
thread::create erzeugt dann einen Thread mittels der C-Funktion create,
die als Parameter die Funktion mit dem auszuführenden Code erwartet, in
diesem Falle ist das thread::execute.
Das hätte dann wohl zur Folge, dass ich alle von thread abgeleiteten
Objekte global halten müßte und jedes mal wo ich ein solches Objekt
erzeuge eine Stubfunktion schreiben müßte. Da muss ich mich wohl
entscheiden, wo ich mein OO-Konzept durchbreche.

@ Rolf
Ich habe auch den Hinweis zu Bound-Member-Function gefunden und
ausprobiert. Es unterdrückt den Cast-Fehler, dafür fehlen eben die
Klasseninformationen (vtable) und es gibt später ein Linkerfehler. Also
Zugriff der C-Funktion auf Klassenmethode, zumal virtuell, geht nicht.

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, aber jetzt steh ich auf dem Schlauch.
Wenn ich Dich richtig verstanden habe, willst Du eigentlich ein
c-Funktion aus einer Methoden-Funktion aufrufen und nicht umgekehrt.
Oder verstehe ich jetzt gar nichts mehr.

Kannst Du evtl. Deine Sourcen zur Verfügung stellen, um Klarheit in die
Sache zu bringen?

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder geht es darum, dass Du Methodenfunktionen der thread-Klasse in der
"globalen c-Thread-Funktion" benutzen willst?

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube jetzt hab ich's:

Du willst die Member-Funktion thread::execute an die globale
c-Thread-Funktion übergeben.
Dies erreichst Du ganz einfach indem Du die Stub-Funktion als Member
der thread-Klasse anlegst. Und diese muss für den globale Zugriff
statisch sein.

[C]

// ich weiss nicht ob das hier weiterhilft, aber in einer
// Windows-Umgebung nutze ich für diesen Zweck folgende Macro's

#define DECLARE_THREAD_FUNCTION(className, functionName)        \
static void functionName(void* classPtr)                \
{                                    \
  ((className*)classPtr)->functionName();                \
}

#define START_THREAD(functionName)  _beginthread(functionName, 0, this)

/////////////////////////////////////////////////////////////////
// Anwendungsbeispiel

im Header deiner Thread-Klasse setzt Du vor der execute-Funktion
folgendes Macro:

DECLARE_THREAD_FUNCTION(thread, execute)

// Dieses Macro erzeugt die statische Stub-Funktion.

// In Deiner create-Funktion benutzt Du dann das:

START_THREAD(execute)

// Beachte dabei, dass Du das START_THREAD-Macros an deine Umgebung
// anpassen musst. Es handelt sich in diesem Beispiel um Code für
// die Windows-Umgebung!

[C\]

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> #define START_THREAD(functionName)  \
  _beginthread(functionName, 0, this)

                                ****

Und hier wird der Knackpunkt liegen. Die wenigsten C-Bibliotheken,
die mit Callbacks arbeiten, haben die Möglichkeit zusätzlich zum
Funktionspointer noch weitere Argumente zur Callbackfunktion
durchzureichen.

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karsten
Wirklich toller Einfall! Ich habe jetzt die Makros von dir ausprobiert.
Der Compiler akzeptiert es, aber der Linker sagt leider "undefined
reference to 'vtable of thread'". Schade!

@all
Ich habe noch ein Teil des Codes angehangen, falls jemand noch ein
bischen Knobeln möchte. Ich werde heute Abend noch am Problem
weitermachen, dann werde ich wohl das Problem umgehen müssen.

Zum Code:
Die Funktion applicationStart in root.cxx ist der Eintrittspunkt vom
RTOS. thread ist die Klasse mit der Threadfunktionalität ( was auch
sonst). cdci_control wird von thread abgeleitet und soll die Anwendung,
die in diesem Thread laufen soll bereitstellen. Auf diese Art und Weise
sollten alle Thread ihre Funktionalität bekommen.
Ach so hier noch die Typdefinition von entry_function:
typedef VOID (* entry_functionType)(ULONG entry_input);

Autor: tom (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
jetzt noch mal mit Code

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl Heinz:

Um auf deine Variante zurück zukommem. Man könnte den MyClass-Pointer
und die Stub-Funktion zu Membern der thread-Basis-Klasse machen und
somit OO-kompatibel bleiben.

Bsp:

class thread
{
  static thread* pCallbackObj;

  static void StubForThreadExecution()
  {
    pCallbackObj->execute();
  }
  ...

  public void create()
  {
    // setze Callback-Pointer
    pCallbackObj = this;

    // erzeuge thread mit create() aus ThreadX-OS
    ::create( StubForThreadExecution );
  }

  public void execute()
  {
    /* letztendlich landet der Call dann hier */
  }
};


Könnte doch klappen oder?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yep.

Löst aber nicht das generelle Problem:
Es gibt nur einen Pointer über den der Callback
geführt wird.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man könnte den MyClass-Pointer und die Stub-Funktion zu Membern
>  der thread-Basis-Klasse machen und somit OO-kompatibel bleiben.

Nein, eigentlich nicht. Funktionen, die aus C heraus aufgerufen werden,
müssen als extern "C" deklariert sein. Das geht bei
static-Memberfunktionen aber nicht. Meistens geht's trotzdem, aber
korrekt ist es streng genommen nicht.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig. Daran hab ich nicht mehr gedacht.

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die vielen tollen und vor allem schnellen Tipps!
Ich habe jetzt die CallbackObject-Variante probiert und die dabei
wieder auftretenden Linker-Fehler untersucht. Dabei habe ich
festgestellt, dass die virtuelle Deklaration von Execute die Ursache
für die Linker-Fehler ist. Die virtuelle Deklaration ist aber
eigentlich Unsinn, da ich ja das Objekt der abgeleiteten Klasse
benutze. Das sollte also die Lösung sein!
Ich werde es morgen gleich auf dem Targetsystem testen.
Gute Nacht allerseits!
Tom

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl Heinz:

Du hast natürlich Recht, wenn Du an die Erzeugung von Thread-Objekten
aus bereits laufenden Thread's denkst.
Die Synchronisation ist nur für den Stub-Funktion notwendig. Ein
bereits laufender Thread kennt seinen this* dann selbst. Denke ich
jedenfalls.
Aber für diesen Fall gibt es ja Synchronisationsobjekte wie Critical
Sections oder Mutexe, um den Zugriff auf die static Ressource zu
synchronisieren.

@Tom:

Wieso ist das mit der virtuellen Create() in der thread-Klasse
Blödsinn? Wenn Du die thread-Klasse als Basisklasse für deine Threads
nutzen willst ist die Virtualisierung der Create-Funktion mehr als
sinnvoll.
Um den Einwand von Karl Heinz zu berücksichtigen, führe in der Create()
ein Synchronisationsobjekt vor dem Zugriff auf den CallbackPtr ein.

z.B.

  public void create()
  {
    // setze hier den Lock
    enterCriticalSection(&cs); // oder was Du zur Verfügung hast

    // setze Callback-Pointer
    pCallbackObj = this;
 
    // erzeuge thread mit create() aus ThreadX-OS
    ::create( StubForThreadExecution );

    // gebe Lock wieder frei
    leaveCriticalSection(&cs);
  }

  // cs sollte in diesem Fall ein globales 
  // Critical Section - Objekt  sein


Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tom:

Sorry, ich meine natürlich die Virtualisierung der Execute Funktion!

Autor: Karsten Brandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mir mal den Header mit der Deklaration der tx_thread_create()
besorgt.

Die tx_thread_create() hat danach folgende Signatur:

UINT tx_thread_create(TX_THREAD *thread_ptr,
                      CHAR *name_ptr,
                      VOID (*entry_function)(ULONG),
                      ULONG entry_input,
                      VOID *stack_start,
                      ULONG stack_size,
                      UINT priority,
                      UINT preempt_threshold,
                      ULONG time_slice,
                      UINT auto_start);

Die Signatur einer Thread-Funktion sieht so aus:

void thread_func(ULONG thread_input)

Mit anderen Worten man kann das Argument thread_input für das
Durchreichen des this* missbrauchen.

Um dann noch einmal auf meine Macro's zurückzukommen, die
Stub-Funktion muss der Thread-Funktionssignatur entsprechen.
Im Falle einer Stub-Funktion als Member der thread-Klasse ist diese
als static zu deklarieren.

Also so:
static void stub_function(ULONG classPtr)
{
  ((className*)classPtr)->Execute(0);
}

Der Aufruf von tx_thread_create() müsste - um bei Deinem Code zu
bleiben - dann folgendermaßen aussehen:
unsigned int thread::Create(char* name_ptr, 
                            unsigned long entry_input, 
                            unsigned int priority, 
                            unsigned int preempt_threshold, 
                            unsigned long time_slice, 
                            unsigned int auto_start) 
{
    return tx_thread_create(thread_ptr,
                            name_ptr,
                            stub_function,
                            (ULONG)this,
                            stack_start,    
                            stack_size,
                            priority,
                            preempt_threshold,
                            time_slice,
                            auto_start);
}

Ob das so funktioniert, habe ich jetzt aber nicht probiert!
So kannst Du die Synchronistationsproblematik umgehen. Aber auf Kosten
der Argumente bzw. Parameter für die Thread-Funktion.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.