3. [gelöst] Problem mit Funktionszeiger

[gelöst] Problem mit Funktionszeiger

  • S

    Der Kompiler gibt keine Fehlermeldung aus. Alles lässt sich wunderbar bauen.

    Wenn ich in in der setData-Funktion von ReceiverThread bin, ist der übergebene this-Pointer (hier *obj) gleich 0.

    0
  • D

    Stonecold_Mario schrieb:

    Der Kompiler gibt keine Fehlermeldung aus. Alles lässt sich wunderbar bauen.

    Wenn ich in in der setData-Funktion von ReceiverThread bin, ist der übergebene this-Pointer (hier *obj) gleich 0.

    Na dann schau mal, wieso der 0 ist. (Dann musst du aber zum Aufrufer von setData gehen.

    Also hier:
    SerialCommunicator::openCommunication

    0
  • S

    Sicher, nur sehe ich nicht warum this nun 0 ist.

    t_receiverThread->setData(&h_comm, &m_readOverlapped, &SerialCommunicator::incommingData, this);
std::cout << "SerialCommunicator::openCommunication(): obj = " << this << " fun = " << &SerialCommunicator::incommingData << std::endl;

    Die Ausgabe zeigt ja eine Objektadresse != 0

    0
  • D

    Wenn du da mit dem Debuger Schrit für Schritt dann in die Funktion reingehst, und vorher die Adresse nicht 0 hast und beim nächsten Schritt ist in der Funktion 0? - Kann ich mir nur schwer vorstellen.

    0
  • S

    Nur mal die Sachen die aufgefallen sind.

    Funktionsaufruf:

    this 0x009f5110 {h_comm=0x00000ee4 m_dcb={...} m_timeOuts={...} ...} SerialCommunicator * const

    h_comm 0x00000ee4 void *

    t_receiverThread 0x009f4d68 {h_comm=0xcdcdcdcd m_readOverlapped=0xcdcdcdcd ptr=0xcdcdcdcd } ReceiverThread *

    p_publisherObject 0x009938dc {serialCom=0x009f5110 hCom=0xffffffff } Publisher *

    Nächster Schritt:
    obj 0x00000000 {h_comm=??? m_dcb={...} m_timeOuts={...} ...} SerialCommunicator *

    h_comm CXX0030: Fehler: Ausdruck kann nicht ausgewertet werden

    t_receiverThread CXX0030: Fehler: Ausdruck kann nicht ausgewertet werden

    p_publisherObject CXX0017: Fehler: Symbol "" nicht gefunden

    Ich erkenne ein Problem. Weiß aber nicht warum es da ist.

    0
  • S

    Sind bezüglich der Meldungen im Debugger nur keine vernünftigen Debuginfos für die Lib erstellt worden? Wo kann ich das im VC2005 für die statische Lib einstellen (/DEBUG)? Linkereinstellungen gibt es für die Lib ja nicht?

    0
  • S

    Okay ich habe hier nochmal das Beispiel von heute morgen so gebaut, dass ebenfalls der selbe Fehler auftritt. Ist jetzt vielleicht einfacher nachzuvollziehen. Ich werde nicht schlau.

    A.h

    #ifndef A_H
#define A_H

class B; 

typedef void (B::*funptr) (void); 

class A { 
 private: 
  funptr ptr; 
 public: 
	 void callFunction(funptr p, B* obj);
}; 

#endif // A_H

    A.cpp

    #include "A.h"

void A::callFunction(funptr p, B* obj) { ptr = p; (*obj.*ptr)(); }

    B.h

    #ifndef B_H
#define B_H

class B { 
 public: 
  void callHallo();

  void run();
};

#endif // B_H

    B.cpp

    #include "B.h"

#include <iostream> 
#include "A.h"

void B::callHallo() { std::cout << "Hallo Welt!\n"; } 

void B::run() 
{ 
A* obj = new A; 
obj->callFunction(&B::callHallo, this); 
}

    main.cpp

    #include "B.h"

int main() { 
  B* obj = new B; 
  obj->run(); 
}

    Es scheint problematisch zu sein, wenn die Funktion callFunction der Klassen A in einer seperaten cpp-Datei implementiert wird. 😕

    Schönen Abend noch!!!

    0
  • D
     

    #include "A.h" //zuerst
#include "B.h"

#include <iostream>

void B::callHallo() { std::cout << "Hallo Welt!\n"; }

void B::run()
{
A* obj = new A;
obj->callFunction(&B::callHallo, this);
}
    0
  • S

    Wow danke,

    genau das war das Problem. Jetzt funktioniert es auch bei meinen Prog.
    Da wäre ich so schnell nicht drauf gekommen, wenn überhaupt.

    Was genau ist jetzt das Problem gewesen. Warum ist es wichtig die Reihenfolge der Includes zu beachten?

    Nochmal danke und Gruß,
    Mario

    0
  • C
    Mod

    Stonecold_Mario schrieb:

    Warum ist es wichtig die Reihenfolge der Includes zu beachten?

    Ist es eigentlich nicht. Du könntest ein Problem mit einer nicht standardgemäßen Optimierung deines Compilers haben (etwa Visual C++: benutz zur Sicherheit den Schalter /vmg). Das Problem würde dann auch nicht auftreten, wenn du Zeiger auf Member nie deklarierst, bevor die betreffende Klasse definiert wurde (was meistens möglich ist; hier: vor der Klassendefinition von A den Header für B einbinden).

    0
  • S

    Okay danke!

    Wie bist du darauf gekommen einfach die Includes zu vertauschen?

    Das Programmstück welches ich dort gerade baue ist eine statische Lib. Deshalb wollte ich in jedem Fall vermeiden einen Nicht-Standard-Header zu includieren.
    Bin echt froh, dass das Problem vom Tisch ist, hat echt aufgehalten.

    Nochmal danke auch an all die Anderen, die sich mit dem Problem beschäftigt haben.

    0
  • D

    Stonecold_Mario schrieb:

    Das Programmstück welches ich dort gerade baue ist eine statische Lib. Deshalb wollte ich in jedem Fall vermeiden einen Nicht-Standard-Header zu includieren.

    Das spielt doch keine Rolle. Es müssen ja so oder so beide Teile vorhanden sein, sonst kann das gar nicht funktionieren. Was unbedingt ferngehalten werden muss, sind Sachen, die mal gar nichts mit deinem Projekt zu tun haben. Respektive nicht zur lib gehören.

    0
  • S

    Ja, aber so reicht es jetzt für weitere Projekte aus, den Header der Lib und die .lib selber zu haben. Ansonsten hätte ich mindestens noch den Klasse B Header benötigt.

    0
Anmelden zum Antworten