QT Signals and Slot frage

downtimes

Hey Leute. Ich hab da mal ne relativ verzwickte Frage zu QT. hab vor dem Wochenende angefangen mal ein bisschen damit rumzuprobieren. Alles lief auch so weit bis ich folgendes Versucht habe:

class Window: public QMainWindow {
  Q_OBJECT

Model* model;

private slots:
  void bar() {}

public:
  Window(Model *mod) : QMainWindow(), model(mod) {
    connect(model, SIGNAL(foo()), this, SLOT(bar()));
    this->show();
  }

};

class Model : public QObject {
  Q_OBJECT

signals:
  void foo();
};

int main(int argc, char* argv[]) {
    QApplication a(argc, argv);
    Model model;
    Window window(&model);
    return a.exec();
}

Er hat mir das ganze schön compiliert und ich konnte es auch ausführen.. Allerdings wurde das Programm direkt nach dem starten wieder ohne Fehlermeldung beendet. Habe ich ein Debug-Build gemacht lief alles einwandfrei...

Nun hab ich den Constructor durch folgendes ersetzt:

Window(Model& mod) : QMainWindow(), model(&mod) {
    connect(model, SIGNAL(foo()), this, SLOT(bar()));
    this->show();
  }

//dementsprechend main anpassen:
int main(int argc, char* argv[]) {
    QApplication a(argc, argv);
    Model model;
    Window window(model);
    return a.exec();
}

Mit dieser Konfiguration funktioniert auch der Release-Build einwandfrei. Nun Frag ich mich ehrlich gesagt, wo bei beiden der große Unterschied besteht und warum das erste nicht funktionieren wollte?
Gemeiner Bug im compiler?? Irgendetwas mit Signals und Slots meinerseits nicht richtig verstanden?

Würde mich über die wildesten Vermutungen freuen.

MFG downtimes

//Edit hat noch ein paar kleinere Fehler gekillt

zwutz

ich geh mal davon aus, dass das nicht der vollständige Quellcode ist. Du löst dein Signal nämlich nirgends aus.

Das connect-Makro erwartet übrigens Zeiger, keine Referenzen. Von daher sollte der Logik nach das erste Beispiel eher funktionieren als das zweite

downtimes

Natürlich ist das nicht der gesammte Quelltext. Ich glaub auch nicht das es etwas mit dem auslösen zu tun hat um ehrlich zu sein.

Das das connect-Makro Pointer erwartet ist mir klar und das wird ja in dem Beispiel eingehalten: beidesmal ist ein Pointer in der Klasse gespeichert. (hatte grade noch den Parameter genommen was natürlich Falsch wäre.. ist aber nicht mein Fehler im "richtigen Programm")

Das einzige was ich am Quellcode geändert habe damit es funktioniert war die Konstruktion der Klasse Window. Dort siehste das einmal im Konstruktor direkt ein Pointer übergeben wird zum Model. Beim funktionierenden Beispiel hingegen übergeb ich eine Referenz und lass mir dann davon die Adresse geben.

Das ist ja gerade mein Problem. Ich versteh nicht wo bei beiden Beispielen der Unterschied sein soll und warum das eine funktioniert und das andere nicht.

Und nachdem ich nun das minimalbeispiel mal eingetippt habe funktioniert das sowohl als auch mit beiden Varianten...Muss wohl also doch an irgend etwas anderem liegen.... gnah sowas macht mich einfach verrückt

Okay kann geschlossen werden nun tuts auf einmal auf wundersame weiße auch mit nem stink normalen Pointer -.-... ich blicks einfach nicht..

MFG downtimes

Sanni

Wenn ich mir den Code ansehe, glaube ich nicht, dass es am Signal-/Slot-Mechanismus liegt. Das kannst du aber rausfinden, wenn du das Programm von der Kommandozeile aus startest. Läge der Fehler in diesem Mechanismus, würde eine Fehlermeldung zum Vorschein kommen. Kannst du das Signal selbst (z.B. über ein Widget) erzeugen? Dann würde auch hier eine Fehlermeldung erscheinen.

Mein Tip: dein code sieht mir etwas 'unsauber' aus. Versuch das ganze mal klarer zu formulieren, dann könntest du rausfinden, was in der ersten Version nicht läuft, um danach herauszufinden, was in der zweiten Version besser ist.