pimpl. Почему работают сигналы из приватного класса? [РЕШЕНО]

[kuzulis]

Доброго времени!

Я сделал небольшой примерчик в котором в приватном классе не унаследованном ни от кого в приватной секции имеется указатель на QTimer.

Код:

#ifndef MYCLASS_P_H
#define MYCLASS_P_H

#include "myclass.h"

class QTimer;
class MyClassPrivate
{
    Q_DECLARE_PUBLIC(MyClass);
public:
    MyClassPrivate();
    virtual ~MyClassPrivate();

    void start();
    void _q_print();

    MyClass * q_ptr;
private:
    int cnt;
    QTimer *timer;
};

#endif // MYCLASS_P_H

И если сделать код, который у меня в примерчике - то можно подключаться к сигналам из приватного класса! О_О

Или я что-то недопонял в концепции.. или я вообще недопонял

1. Почему работают сигналы, ведь приватный клас не унаследован от QObject и в нем нет макроса Q_OBJECT? (про слоты с префиксом _q_ в приватных классах я в курсе)
2. Можно ли кодить применяя этот подход?

Проект в аттаче

[lit-uriy]

что-то я не вижу сигналов ни в одном из классов

[kuzulis]

что-то я не вижу сигналов ни в одном из классов

ну от QTaimer-a сигналы
timer же находится в приватном классе -> по идее сигналы от него не должны обрабатываться

[BRE]

1. Почему работают сигналы, ведь приватный клас не унаследован от QObject и в нем нет макроса Q_OBJECT? (про слоты с префиксом _q_ в приватных классах я в курсе)
2. Можно ли кодить применяя этот подход?

Ну так ты же используешь:
Q_PRIVATE_SLOT
и moc этого пропустить не может. 

[kuzulis]

Ну так ты же используешь:
Q_PRIVATE_SLOT
и moc этого пропустить не может.

Ну я так понял, что эта фича делает из _q_print() слот... Но каким образом это относится к сигналам от таймера?
Если я сделаю слот в паблик классе MyClass и сделаю коннект - то тоже будет работать!

Прицепил аттач новый

[lit-uriy]

да собственно сигналы от таймера не вызывают удивления.
мне например непонятно как соединение осуществляется для класса не наследника QObject.

[lit-uriy]

так стоп.
полная запись вот такая:
q->connect(timer, SIGNAL(timeout()), q, SLOT(_q_print()));
где q - наследник QObject и в нём указан макрос Q_OBJECT

[kuzulis]

да собственно сигналы от таймера не вызывают удивления.

И? Поделитесь секретом! В чем "фишка" ? В том что parent у таймера это q ?

мне например непонятно как соединение осуществляется для класса не наследника QObject.

в смысле?

[kuzulis]

так стоп.
полная запись вот такая:
q->connect(timer, SIGNAL(timeout()), q, SLOT(_q_print()));
где q - наследник QObject и в нём указан макрос Q_OBJECT

ааа.. начинает доходить!

Ну так значит такой код (идея) имеют место на существование? т.е. в том смысле, что указатели на объекты которые должны емиттить сигналы расположены в приватном классе?
т.е.

Код:

class MyClassPrivate
{
....
....
....
private:
    int cnt;
    QTimer *timer; // вот про это я имею ввиду!!
};

просто я нигде в примерах и исходниках Qt4 не встречал такого (или просто не попалось на глаза) и мне нужно именно так реализовать решение, вот я и спрашиваю

[lit-uriy]

>>В чем "фишка" ? В том что parent у таймера это q ?
родитель не причём, у QTimer'а есть сигнал и он посылается при внутреннем событии таймера, независимо ни отчего (если их явно не блокировать).
Сигналы и слоты реализуют идею компонентного программирования, т.е. компонент (QTimer) максимально автономен.

[lit-uriy]

В целом такой подход (без наследования от QObject) я считаю плохим, т.к. макрос Q_PRIVATE_SLOT отсутствует в открытом описании API, т.е. его нет в Assistant'е

[BRE]

так стоп.
полная запись вот такая:
q->connect(timer, SIGNAL(timeout()), q, SLOT(_q_print()));
где q - наследник QObject и в нём указан макрос Q_OBJECT

ааа.. начинает доходить!

На самом деле не обязательно использовать q->connect.
connect это статический метод QObject, т.е. можно просто
QObject::connect( ... );

[kuzulis]

В целом такой подход (без наследования от QObject) я считаю плохим, т.к. макрос Q_PRIVATE_SLOT отсутствует в открытом описании API, т.е. его нет в Assistant'е

Почему?

хм, а вот в блоге: http://habrahabr.ru/blogs/qt_software/76506/

автор говорит что:

Приватные слоты — это механизм дополняющий функционал d-указателей. Он позволяет реализовать слоты для приватного класса, даже если он не является наследником от QObject (обычно он им и не является), но для этого публичный класс должен быть наследником от QObject. Тоесть по факту создается некий приватный слот в публичном классе и он непосредственно дергает нужный метод приватного класса.
Зачем это нужно? Ну рассмотрим на примере. Есть класс QAbstractScrollArea. Он просто отображает некий виджет (viewport) и обеспечивает прокрутку. Прокрутка обеспечивается с помощью двух экземпляров класса QScrollBar. Сами эти скролбары он хранит в приватном классе. Теперь проблемма: как подключить сигнал от скроллбара об изменение его позиции с классом QAbstractScrollAreaPrivate, ведь он не является QObject'ом? Сделать его наследником от QObject — лучше не делайте это :-) . Можно сделать слот в публичном классе и повесить на него, то в таком случае это не очень красиво — так как наружу выходят слоты от внутренней реализации. Вот ту Qt-шниками был придуман достаточно разумный и элегантный подход — приватные слоты.

да и в исходниках Qt4 приватные классы НЕ наследуются от QObject!

На самом деле не обязательно использовать q->connect.
connect это статический метод QObject, т.е. можно просто
QObject::connect( ... );

в исходниках Qt я только что заметил, что делают именно q->connect()!

О_О в общем пока непонятно.. неразбериха

[lit-uriy]

>>Почему?
Дык, яж написал:
"...т.к. макрос Q_PRIVATE_SLOT отсутствует в открытом описании API, т.е. его нет в Assistant'е"
Завтра троли переделают потраха, и ты будешь плакать

[Авварон]

там 90% макросов нет. и например они сами его юзают в креаторе