D pointers #2

[Michael Pyne]

On Wednesday 19 October 2005 12:36, Oswald Buddenhagen wrote:
> On Wed, Oct 19, 2005 at 02:06:22PM +0200, Lubos Lunak wrote:
> > +       B::B()
> > +       {
> > +               disconnect( this, SIGNAL( bar( int* )), this, SLOT(
> > barslot( int* ))); +               connect( this, SIGNAL( bar( int* )),
> > this, SLOT( barslot( int* ))); +       }
> > +
> > Note [...] that in the constructor it is necessary to first disconnect
> > and then connect again, that will disconnect A::barslot() and connect
> > B::barslot() instead.
>
> that's beyond me ...
> doesn't A::A() already connect to B::barslot() because slots have
> virtual behavior by nature?
> or, the other way round, why should QObject::connect() do a different
> thing when called with the same parameters from different places? am i
> missing some deep magic?

Now I could be thinking things wrong here, but if I know my obscure C++ 
correctly, nothing is virtual in nature within the constructor of a class.

That is, A::A()'s connect call will always access methods of class A even that 
the moc declares the functions to be virtual.  Because at this point in the 
instantiation, the ctor for A can't know whether or not a ctor for a derived 
class will be run or whether the class will remain as an A.

Well, maybe it does know, I know that the ABI seems to have a difference 
between certain kinds of ctors based on problems like that but as far as I 
understand C++ being in a constructor implies that the virtual dispatch 
mechanism is temporarily disabled.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051019/b76ce301/attachment.sig>