[Qt-interest] Qt, C++ Namespaces, and Signals/Slots

[BRM]

Well, to follow up (and that e-mail took a long time for some reason to reach the list so I couldn't follow up earlier) I had recently redirected some information output by qDebug to my program's internal log, and mistakenly was looking in the wrong place. Everything seemed to have worked, and I didn't see any statements about signals/slots not connecting so it seemed to be working; I was later looking at the logs for other things when I noticed it wasn't really working - I just wasn't exercising the relevant signals/slots at all any more so it didn't make a lick of difference in the program any way. So my original question is invalid.

Either way, the below is very useful information; though I think it is rather obvious that sub-classes are not supported that way since they would have to be QObject derivatives in themselves and MOC doesn't like having subclasses derived from QObject defined like that (if I understand things correctly); so they would need their own headers/implementation files any way to be able to interact with signals/slots. I am strictly only dealing with namespaces; though that does lead me to another question now that I think about it - is MOC and Qt Signals/Slots smart enough to match a typedef'd version with its original? Or to follow namespace renaming? 

Example 1:
namespace X {
   enum someEnum {...};
}
...
typedef X:someEnum myLocalEnum;
...
connect(_a,SIGNAL(someSignal(X:someEnum)),_b,SLOT(someslot(myLocalEnum)));


Example 2:
namespace X {
   namespace Y {
     enum someEnum {...};
   }
}
...
namespace W = X:Y;
...
connect(_a,SIGNAL(someSignal(X:Y:someEnum)),_b,SLOT(someslot(W:someEnum)));


Ben


----- Original Message ----
> From: Constantin Makshin <cmakshin at gmail.com>
> To: Qt Interest <qt-interest at trolltech.com>
> Sent: Thu, June 24, 2010 12:28:52 PM
> Subject: Re: [Qt-interest] Qt, C++ Namespaces, and Signals/Slots
> 
> Parameters of SIGNAL() and SLOT() macros must be exactly equal to corresponding 
> signal/slot declaration. So in your example the connect() statement should look 
> like this:

connect(_a, SIGNAL(someSignal(X:Y:anEnum)), this, 
> SLOT(someSlot(X:Y:anEnum));

And remember that Qt's meta object system 
> doesn't support nested types. For example:

class 
> ClassA
{
public:
    class SubClassA
    
> {
        ...
    };

    
> ...

signals:
    void someSignal (const 
> ClassA::SubClassA&); // <- !!!
};

class ClassB
{
  
>   ...

public slots:
    void someSlot (const 
> ClassA::SubClassA&);
};

Note that you have to write complete 
> parameter type specifier in someSignal() because if you write it as "void 
> someSignal(const SubClassA&);", it'll be correct from C++ point of view, but 
> any attempt to connect someSignal() and someSlot() will fail with "parameter 
> type mismatch" type of error. I had this problem during development of one of my 
> applications and would like to help you to avoid it. :)

On Thursday 24 
> June 2010 19:19:21 BRM wrote:
> I am moving around some definitions from a 
> Qt-only header set to a shared Qt and Standard C++ header sets.
> In the 
> new header sets I am utilizing C++ namespaces. Updating everything seems to have 
> gone fine, but thus far I've only tested using MSVC.
> Presently this just 
> applies for a series of enums, and a few structures as well; a number of these 
> get used in signals and slots.
> Not every use of the types warrants the 
> implementation file having a using namespace for the namespace these are stored 
> in - and I will have multiple levels of namespaces.
> 
> What I am 
> curious about is that in one case the function definitions for the signals/slots 
> included the namespaces;
> however, I didn't put the namespaces in the 
> connect() statement - or the SIGNAL()/SLOT() sub-parts of it; yet, Qt seems to 
> have made the right connections, and allowed it.
> I expected I would have 
> to update the SIGNAL()/SLOT() to have the namespace parts in it too. Presently I 
> have only noticed this for some standard C++ enums that I reference.
> But 
> I am wondering if this is by design or some fluke - e.g. can I rely on this, or 
> should I really namespace the parameters?
> 
> Where I have used 
> qRegisterMetaType<>() to register something I did add in the namespace 
> referencing, but I have not done that in all cases.
> 
> 
> Example:
> 
> namespace X {
>     namespace Y 
> {
>         enum anEnum {
>      
>        anEnumValue1=0,
>          
>    anEnumValue2,
>            
> ...
>         };
>     }
> 
> }
> 
> class myQtClassA : QObject {
> ...
>    
> Q_SIGNALS:
>        void 
> someSignal(X:Y:anEnum...);
> ...
> };
> 
> class 
> myQtClassB: QObject {
> ...
>    public 
> Q_SLOTS:
>        void someSlot(X:Y:anEnum);
> 
> ...
> };
> 
> myQtClassB::someFunction(myQtClassA* 
> _a){
>     ...
>    
> connect(_a,SIGNAL(someSignal(anEnum)),this,SLOT(someSlot(anEnum));
>  
>    ...
> }
> 
> TIA,
> 
> 
> Ben
_______________________________________________
Qt-interest mailing 
> list

> href="mailto:Qt-interest at trolltech.com">Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest