Fehlermeldung IAR Compiler - Probleme mit Zeiger

[zorro (Gast)]

Hallo,

ich möchte einen Zeiger casten. Sobald ich das C-File übersetzen möchte, 
erscheint eine Fehlermledung vom Compiler.

H-File

void(*SetCallBack)(obSTM32UART*, void(*)(void*), int(*)void*,char*,int*), void*);

C-File
Konstruktor:

// geerbte Methoden
pthis->pM->SetCallBack = (void(*)(obFramePort*, void(*)(void*), int(*)
(void*,char*,int*), void*))pthis->Parent.pM->SetCallBack;

Der Compiler meldet folgenden Fehler:

Error[Pe513]: a value of type "void (*)(obFramePort *, void (*)(void *), int (*)(void *, char *, int *), void *) type "void (*)(obSTM32UART *, void (*)(void *), int (*)(void *, char *, int *), void *)"

In der geerbten Methode soll der erste Parameter "obFramePort*" 
weiterhin existieren.

Vielen Dank im Voraus!

[(prx) A. K. (prx)]

Magts du keine Typedefs? Bei Zeigern auf Funktionen sind die recht 
hilfreich.

[(prx) A. K. (prx)]

Wenn beide SetCallBacks wie gezeigt deklariert sind, aber obSTM32UART 
und obFramePort verschiedene Typen sind, dann kann ich den Compiler gut 
verstehen.

[zorro (Gast)]

Das ist mir klar das der Compiler Probleme damit hat. Beim anderen 
Compiler gibt es allerdings keine Probleme. Was könnte ich nun in meine 
Fall tun ?

[(prx) A. K. (prx)]

zorro schrieb:

> Beim anderen Compiler gibt es allerdings keine Probleme.

Interessant. Machen die bei
  int *p = (double *)&x;
auch keine Probleme? Diese Sorte Compiler solltest du meiden.

> Was könnte ich nun in meine Fall tun ?

Die komplette Fehlermeldung hier unterzubringen (umgebrochen) wär schon 
mal ein Anfang. Die oben sieht abgebrochen aus.

Ausserdem frage ich mich, was der Cast da überhaupt soll. Wenn beide 
SetCallBacks gleich deklariert sind, wozu soll der dann gut sein? Was 
spricht gegen
  pthis->pM->SetCallBack = pthis->Parent.pM->SetCallBack;

Und wenn sie nicht gleich deklariert sind, dann wär das mal wieder ein 
klassisches Beispiel für Salamitaktik in Foren.

[zorro (Gast)]

Es gibt noch das Objekt "obFramePort". Diese Klasse ist ein virtuelles 
Objekt und soll eine Hardwareschnittstelle kapseln.

[Karl H. (kbuchegg)]

zorro schrieb:
> Das ist mir klar das der Compiler Probleme damit hat. Beim anderen
> Compiler gibt es allerdings keine Probleme. Was könnte ich nun in meine
> Fall tun ?

erstmal: typedefs!

Da kriegt man doch Augenkrebs. Funktionspointer ohne typedefs sind ein 
pain in the ass! Das kann doch kein Mensch mehr nachvollziehen ob alle 
Klammern auch wirklich dort sind, wo sie hingehören!

[zorro (Gast)]

Hier nochmal die Fehlermeldung --> siehe Dateianhang.

[Karl H. (kbuchegg)]

Da hat der Compiler allerdings recht. Der erste Parameter ist ein 
anderer.

Ein obSTM32UART* ist nun mal kein obFramePort*

[Karl H. (kbuchegg)]

Ich weiß ja nicht was du da machst. Aber für mich sieht das alles nicht 
koscher aus. Dieses ewige Rumgecaste von Funktionspointern sieht mehr 
eher nach einem Hinweis für ein verkorkstes Design aus.

(Der Code kommt mir bekannt vor. Das war doch erst vor ein paar Tagen 
mit ähnlichen Datentypen)

[zorro (Gast)]

Ok das sehe ich auch so. Die SetCallBack Methode rufe ich in meinem 
Hauptprogramm auf. Zuvor lege ich ein Objekt vom Typ obSTM32UART an.

obSTM32UART       Port;

void CallbackFkt(void)
{
...
}


void main (void)
{
...
Port.pM->SetCallBack(&Port,CallbackFkt, 0, 0);

 while(1)
 {

 }
}

[Karl H. (kbuchegg)]

Nochmal: mach dir typedefs für die Datentypen der Funktionspointer.
Ohne verlierst du den Überblick ganz schnell.

Wenn du eine Funktion aufrufst (SetCallback), dann muss das Argument 
auch vom geforderten Datentyp sein. Das gilt auch für Funktionspointer.

Wenn es das nicht ist, dann muss man sich überlegen, ob man gefahrlos 
casten darf oder nicht. Das kommt aber auch darauf an, was die Funktion 
mit dem Argument macht. Wenn das nur ein Durchreichargument ist, d.h. 
die Funktion kriegt einen Zeiger, macht aber selbst nichts damit, 
sondern rückt den Zeiger wieder unverändert raus, dann darf man ihn 
zurechtcasten. In allen anderen Fällen ist ein Pointer-Cast aber 
tödlich!

[(prx) A. K. (prx)]

Salamitaktik vom Feinsten. Das Problem kreist nun schon ein Dutzend 
Posts um obFramePort und "zorro" allein weiss was das ist.

[Karl H. (kbuchegg)]

Du redest die ganze Zeit von C-File, verwendest aber immer wieder den 
Ausdruck "Konstruktor", der eigentlich auf C++ hinweisen würde. Welches 
ist es denn nun?

[zorro (Gast)]

Ok vielen Dank für eure Unterstützung.

[(prx) A. K. (prx)]

Hab ich mich auch schon gefragt. Allerdings sieht das nach nix Halbes 
und nix Ganzes aus, denn was soll "pthis" in C++ sein? Nope, "zorro" ist 
wohl zu sehr Geheimniskrämer um ohne stundenlanges Rumgefrage mit genug 
Info rauszurücken.

[Karl H. (kbuchegg)]

Karl Heinz Buchegger schrieb:
> Du redest die ganze Zeit von C-File, verwendest aber immer wieder den
> Ausdruck "Konstruktor", der eigentlich auf C++ hinweisen würde. Welches
> ist es denn nun?

Der Grund:

In C++ sind solche Dinge extrem selten und ein sehr sicheres Indiz für 
einen Designfehler. In C++ sieht man zu, dass man den Callback möglichst 
schnell in die Klassenstruktur einschleust und den Rest macht man mit 
virtuellen Funktionen anstelle von Funktionspointer-Rumcasten. Auch 
Funktor Objekte kann man da mehr als sinnvoll einsetzen. Auf jeden Fall 
ist aber eine saubere und richtige Klassenhierarchie der Schlüssel zum 
ganzen. Und wenn die stimmt, dann passen die Einzelteile wie 
Puzzlestücke ineinander ohne dass man Casten muss.