Seite 1 von 1

Parameter bei Signal/Slot-Verb.

Verfasst: 20. Oktober 2012 11:34
von Tilman Räger
Hallo,


ist es eigentlich möglich, als Parameter-Typ einer Signal-Slot-Verbindung eine virtuelle Klasse anzugeben, d.h. als eigentlich zu übergebende Objekte dann welche, die von dieser Klasse abgeleitet sind?

(Bsp. virtuelle Basisklasse Fahrzeug, abgeleitete Klassen Motorrad, PKW, LKW, Fahrrad -> Signal definiert als 'mySignal(Fahrzeug)' )

Ziel ist, ein Objekt dieser Klasse an ein (mglw. in einem anderen Thread laufendes) Objekt zu übergeben, wobei das Einlesen im MainThread und die spätere Verarbeitung im anderen Thread jeweils Typabhängig sind.

Gruss
Tilman (Räger)

kl. Zusatzfrage:

wenn es möglich ist, muss ich nur die Basisklasse oder auch die jeweils abgeleiteten Klassen mit 'RegisterMetaType' bekannt machen?

Tilman

Re: Parameter bei Signal/Slot-Verb.

Verfasst: 20. Oktober 2012 11:55
von Christian81
Was willst Du da mit RegisterMetaType? Einfach den Pointer als Parameter übergeben und gut ist.

Re: Parameter bei Signal/Slot-Verb.

Verfasst: 20. Oktober 2012 12:39
von Tilman Räger
Hallo,

wenn ich den Pointer übergebe, muss ich mich hinterher darum kümmern, wer das Objekt wegräumt ausserdem habe ich u.U. 2 Klassen, die darauf zugreifen wollen. Meine Idee war, der verarbeitenden Klasse eine Kopie zu übergeben und gut ist. Die lesende Klasse kann ihr Objekt verwenden um ggf. ein weiteres einzulesen, die verarbeitende Klasse kann die Dinger erst mal zwischenspeichern und dann weiter verarbeiten.

Möglich wäre natürlich auch, das Objekt in der lesenden Klasse mit new zu erzeugen, den Pointer zu übergeben und in der Lesenden Klasse dann zum Schluss mit delete platt zu machen. Hätte den Vorteil, das man es bei Aufteilung in Threads schnell mit einem moveToThread in den Verarbeitungsthread hinüberschieben kann (?)

Die Frage ist natürlich, ist der erste Weg überhaupt gangbar, s. meine Ursprungsfrage?


Tilman

Re: Parameter bei Signal/Slot-Verb.

Verfasst: 20. Oktober 2012 12:56
von franzf
Möglich wäre natürlich auch, das Objekt in der lesenden Klasse mit new zu erzeugen, den Pointer zu übergeben und in der Lesenden Klasse dann zum Schluss mit delete platt zu machen. Hätte den Vorteil, das man es bei Aufteilung in Threads schnell mit einem moveToThread in den Verarbeitungsthread hinüberschieben kann (?)
Öha... Sind deine Signal-Parameter von QObject abgeleitet? Dann wars das nämlich schon mit Kopieren...
Außerdem: Was für einen Sinn hätte es, Objekte im verarbeitenden Thread zu erzeugen und wieder zu zerstören? Warum dann überhaupt threadübergreifende Connections?

Was hältst du davon:
* Du hast einen Fahrzeugpool, in dem du deine Fahrzeuge ablegst.
-> add/remove/get
* Jedes Fahrzeug hat eine eindeutige ID (typedef long ID; o.Ä.):
ID Pool::add(Fahrzeug*);
bool Pool::remove(ID);
Fahrzeug* Pool::get(ID);
* Signal/Slot tauschen nur IDs aus, Slot holt sich dann aus dem Pool das Fahrzeug mit der übergebenen ID.

Lustig wäre dann auch, wenn der Pool keine Fahrzeug-Pointer rausrückt, sondern Proxies. Alle Proxies auf eine ID teilen sich eine Mutex, so kannst du verhindern, dass mehrere Threads parallel an einem Fahrzeug rumpfuschen.

Re: Parameter bei Signal/Slot-Verb.

Verfasst: 20. Oktober 2012 13:15
von Tilman Räger
Hallo,

ad 1) ja - die Signalparameter sind von QObject abgeleitet (was allerdings nicht unbedingt notwendig wäre). Copy-Construktor und Zuweisungsoperator existieren (ohne übergabe des Parent - ich vermute mal, das wäre das Problem)

Zur Sache, warum gleich wieder zerstören, muss ich weiter ausholen.
Das ganze ergibt eine Anwendung, die von aussen SQL-Anfragen hereinbekommt, diese an die entsprechenden Datenbanken weiterleitet, die Antwort schön verpackt und an die anfragende Stelle zurücksendet. Da die Sache mit der Datenbank-Abfrage mglw. etwas länger dauern kann, überlege ich noch, diesen Part in eigene Threads auszulagern.

Die Signalparameter sind die einzelnen Anfragen, die protokollspezifisch aus den jeweiligen über Socket eingelesenen Daten erzeugt werden und dann an die Klasse (den Thread) für die Datenbank-Abfrage weitergeleitet werden. Insofern wäre die von mir skizzierte Behandlung Erzeugung in der einen Klasse, dann Verarbeitung und Vernichtung in der anderen Klasse durchaus sinnvoll. Da eine parallele Verarbeitung mehrere Anfragen nicht vorkommen soll, ist eine Speicherung im Erzeugenden Teil nicht erforderlich. Der bekommt dann abschliessend eine ByteArray zum zurücksenden an den Sender der Abfrage.

Ich hoffe, ich hab das ganze einigermassen verständlich erläutert :-) .

Tilman