[Qt-interest] need help with qobject connect

[Andreas Pakulat]

On 10.08.09 17:54:52, Ivan Lyapunov wrote:
> 2009/8/9 Thiago Macieira <thiago.macieira at trolltech.com>
> 
> > Ivan Lyapunov wrote:
> > >It's not the only one purpuse to indicate something to signal emitter
> > > with non-const reference.
> > >I want to change my struct during the emission, since the emission queue
> > > is serialized by Qt and it's not a multithread.
> >
> > That's where you're wrong.
> >
> > It's not serialised. It's a simple copy and you cannot create copies of
> > references.
> >
> 
> I mean SLOTs called consistently in a queue order.

As I said already, the order of this queue is undefined, meaning it
could potentially change depending on the phase of the moon.

> > >So i can change any parameter in struct in first SLOT to the end of
> > >connectors in a connection order, like in a filter.
> >
> > Signals and slots should be regarded as all independent from each other.
> > Depending on an earlier slot running sounds like a bad design to me.
> 
> I can't see any technical problems to do this - only design complexity.

See above, the order in which your slots are called is not defined. The
current implementation calls them in the order the connections where
made, but this can change any day (well with any Qt release). So your
app can seriously break with any new Qt version.

And implementing this properly is just a few lines of code, its IMHO not
worth the given uncertainty when relying on the current implementation.

> > >But unfortunately i should rewrite my code to void* calls because of
> > > strange architect prohibition.
> >
> > I would recommend instead that the called slots' objects have a link to
> > the structure that they're filtering an acting on.
> >
> > Alternatively, you can pass a type that wraps the reference but is
> > copyable.
> 
> I just want to use this queue feature

There is no such feature, its just a side-effect of the current
implementation of signals/slots.

> Making a link is not really good idea for me because it's dynamically
> created
> object in a private class and i haven't access to it.

I don't see what that has got to do with it, if you have a slot thats
supposed to modify an object, that slot knows about the structure of
that object and it doesn't matter wether he gets that object as argument
or wether its taken from an easily accessible structure via a pointer or
some such..

> It's not really trouble, but it's the Qt prohibition and that I can't
> understand, especially
> because of SIGNAL/SLOT mechanist does not have a real safe type checking.

Apparently you didn't understand why passing a reference via
signals/slots that cross thread boundaries (i.e. via queued
connections). The point is that the object thats being referenced has
most probably already gone when the slot is being called. Thats unsafe.
And the signals/slots arguments are type-safe, they only allow the same
types to be used on both the signal and the slot.

Andreas

-- 
This will be a memorable month -- no matter how hard you try to forget it.