[Qt] QMap "geht verloren"

[peschmae]

Ich steh gerade wie der Ochs vorm Berg.
Ich hab da eine QMap<QString, QString> in einem Objekt der Hauptklasse meines Programms und möchte die nun via dessen Konstruktor einem anderen Objekt weitergeben (das die QMap wiederum weitergibt bis sie am Ende am richtigen Ort ist).
Der Konstruktor des Objekts schreibt das Ding in eine Private Variable - Check im Konstruktor gibt aus dass alles OK ist (d.h. die QMap enthält ein Element) aber wenn ich dann eine Member-Methode desselben Objekts aufrufe enthätl die QMap plötzlich nix mehr

Der Code: http://gnu.buildtolearn.net/qmailwatch.tar.bz2
[Edit]Beim Bauen: Auch das Plugin in plugins/maildir kompilieren - sonst findet das Hauptprogramm gar keine Plugins und das Problem tritt nicht auf[/Edit]
Relevant dürften sein:
watchdialog.cpp - letzte Methode, anlegen von WatchButton und aufrufen des Edit-Slots
watchbutton.cpp Konstruktor
watchbutton.cpp edit() - Slot

Wäre extrem nett wenn sich das jemand mal angucken könnte. Bei der Gelegenheit wäre natürlich allgemeine Code-Kritik auch nicht schlecht, aber zuerst bitte das Problem

Oder hat jemand eine extrem schlaue Möglichkeit wie ich eine Variable quer durch das ganze Programm verbreiten kann (nicht static, da sie erst beim erstellen des Haupt-Objekts initialisiert werden kann)

MfG Peschmä

[anda_skoa]

Das müsste schon so passen, das Problem liegt vermutlich im "Java" Teil des Codes

Du versuchst wie in Java in einem Konstruktor die andere Version aufzurufen, das geht in C++ nicht.

Der obere Konstruktor sollte funktionieren.

Ciao,
_

[peschmae]

Jä so. Vielen Dank dass du dir die Zeit genommen hast.

Wie macht man das denn? Eine separate Methode die von allen Konstruktoren aufgerufen wird?

MfG Peschmä

[anda_skoa]

Genau.

Deine beiden Konstruktoren sind aber eh leer, hast also eh nix zum gemeinsam benutzen

Ciao,
_

[peschmae]

Ging auch nicht konkret um den Konstruktor

Ausserdem ists immerhin eine ganze Zuweisung

MfG Peschmä

[peschmae]

Habe schon wieder so ein Problem ala "ich tu was wohin und nachher ist es weg ohne dass ich was gemacht habe":

(PluginLoader Z. 57)

PluginInterface* PluginLoader::getPlugin(const QString path) {
	...
	PluginInterface* p = pl();
	std::cout << "A " << p->checkPath("/irgendwas") << " " << p << std::endl;
	return p;
}

Output: A 0 0x80b1810

und dann: (ConfDialog.cpp Z. 33)

	PluginInterface* p = pluginLoader->getPlugin(pluginLoader->getPath(pluginComboBox->currentText()));

	std::cout << "B " << " " << p << std::endl;
	std::cout << p->checkPath("/irgendwas") << std::endl;
	std::cout << "C" << std::endl;

Output: B 0x80b1810
Speicherzugriffsfehler

Also Speicherzugriffsfehler beim Ausführen der Memberfunktion checkPath() von PluginInterface.
Das Teil ist aber immer noch am gleichen Ort im Speicher wie eben vorher als die getPlugin()-Methode aufgerufen wurde.
pluginLoader ist natürlich eine Instanz von PluginLoader.

Der ganze Programmcode ist wieder unter http://gnu.buildtolearn.net/qmailwatch.tar.bz2

MfG Peschmä

[anda_skoa]

Ausserdem ists immerhin eine ganze Zuweisung

Die du dir ansich sogar sparen kannst, weil du das auch in der Initialisierungsliste machen kannnst

Klasse::Klasse(const StringMap& map) : BasisKlasse(), plugins(map)
{
}

Habe schon wieder so ein Problem ala "ich tu was wohin und nachher ist es weg ohne dass ich was gemacht habe":

Das wesentlich hast du mit "..." rausgenommen :P

QLibrary lib(path);

erzeugt eine QLibrary Instanz am Stack, wird also am Ende von ::getPlugin wieder zerstört.
In der Doku steht "The library will be unloaded in the destructor."

Der Code für p->checkPath ist also beim zweiten Aufruf nicht mehr vorhanden.

Ciao,
_

[peschmae]

Ach so. Ich hatte irgendwie das Gefühl dass wenn ich ja das Objekt habe es egal ist wenn nachher die QLibrary gelöscht wird.

Die Initialisierungsliste werde ich wohl auch mal verwenden - der (oder die?) Syntax ist mir aber irgendwie nicht ganz geheuer.

Danke

MfG Peschmä

[anda_skoa]

Ach so. Ich hatte irgendwie das Gefühl dass wenn ich ja das Objekt habe es egal ist wenn nachher die QLibrary gelöscht wird.

Das Objekt hast du natürlich schon noch, aber wenn der dazugehörige Code nicht mehr das ist, hat das ziemlich den selben Effekt.

Die Initialisierungsliste werde ich wohl auch mal verwenden - der (oder die?) Syntax ist mir aber irgendwie nicht ganz geheuer.

Ist eigentlich nur ein weiterer Konstruktoraufruf, also so wie man eben Parameter an den Konstruktor der Basisklasse weitergibt.

Ciao,
_

[peschmae]

Das Objekt hast du natürlich schon noch, aber wenn der dazugehörige Code nicht mehr das ist, hat das ziemlich den selben Effekt.

Ich hatte angenommen dass das zusammengehört.

Ist eigentlich nur ein weiterer Konstruktoraufruf, also so wie man eben Parameter an den Konstruktor der Basisklasse weitergibt.

Das was mich n bisschen stört ist der Aufruf
pluginLoader(pldr)
mit den Klammern - das sieht doch arg nach Copy-Constructor aus für mich. Und das ists ja nicht, weil PluginLoader gar keinen entsprechenden Copy-Constructor besitzt.

MfG Peschmä

[anda_skoa]

Ich hatte angenommen dass das zusammengehört.

Natürlich, darum gibts auch einen Runtimefehler, wenn eines davon nicht mehr da ist.

Das was mich n bisschen stört ist der Aufruf
pluginLoader(pldr)
mit den Klammern - das sieht doch arg nach Copy-Constructor aus für mich. Und das ists ja nicht, weil PluginLoader gar keinen entsprechenden Copy-Constructor besitzt.

Falls du von watchbutton sprichst, dort is pluginLoader als PluginLoader* deklariert, der Pointertyp kann sehrwohl mit einer Pointeradresse initialisiert werden.

Welche Konstruktoren die Klasse hat, auf die der Pointer zeigt, ist da nicht von Bedeutung, die API der Klasse wird ja nicht gebraucht.

Ciao,
_

[peschmae]

Natürlich, darum gibts auch einen Runtimefehler, wenn eines davon nicht mehr da ist.

Ich meinte zusammengehört insofern als dass wenn ich das Objekt habe damit der Code garantiert auch da ist (d.h. der Code ist im Ram und nicht nur wies scheinbar der Fall ist die Daten des Objekts nicht aber die Methoden der Klasse).

Falls du von watchbutton sprichst, dort is pluginLoader als PluginLoader* deklariert, der Pointertyp kann sehrwohl mit einer Pointeradresse initialisiert werden.

Welche Konstruktoren die Klasse hat, auf die der Pointer zeigt, ist da nicht von Bedeutung, die API der Klasse wird ja nicht gebraucht.

Ach so, doch. Tönt logisch.

MfG Peschmä