Russian Qt Forum

Мне нужно расширить стандартные контролы Qt рядом функций. Они должны уметь перемещаться по родительскому виджету не вылезая за его границы, выдавать данные о своей геометрии, реагировать на набор общих сигналов. Все эти функции совершенно одинаковы для всех контролов, которые все являются виджетами. Но еще они должны принимать и отправлять, различные сигналы, и выполнять дополнительные функции, которые специфичны для каждого класса виджета.

Код общих методов написан и отлажен на примере одного контрола, но сейчас при создании других контролов придётся дублировать как тела методов, так и их объявления в заголовках. Тупо можно было бы и макрос написать, но шаблоны мощнее и современнее. Если бы в Qt было разрешено множественное наследование от QObject, я бы сделал всё очень просто. Но увы, так нельзя. Если бы у классов не было различий, можно было бы все контролы накрыть одним шаблоном и узбагоиться. Но из-за наличия существенных различий контролов, классы примерно на 50% одинаковые, и на 50% различаются. Похоже это надо делать на специализированных шаблонах. Я их совместно с Qt не использовал (честно говоря, вообще в реальных приложениях ни разу не использовал), поэтому вопрос - нет ли каких-либо подводных камней при использовании специализированных шаблонов в контексте GNU CC/MinGW и Qt конкретно версии 4.7? Кто-нибудь использует эту технику в реальных проектах? Вообще моя задача решаема этим способом?

А так ли здесь нужны шаблоны?
Пишите свой базовый класс, в котором реализуете все общие методы, а от него уже наследуете другие контролы, в которых дописываете только  специфмчные для них методы. и т.д.
Или я чего-то не понял?
 

А по-моему нужны (вот уж никак не ожидал себя в такой роли :)). Дело в том что базовый класс не может быть QObject, ему придется включать напр QLineEdit (или др Qt контрол) агрегатом - и это здесь очень неудобно. Напр QLineEdit получил сигнал - и что, надо передавать в базовый, а тот не QObject (и понеслась)

Почему?
Базовый класс наследуется от QWidget, т.к.

Но не "одним и тем же виджетом/классом". Унаследовавшись от QWidget - уже не унаследоваться от того же QLineEdit

QWidget наследует от QObject. Все стандартные контролы тоже наследуют от QWidget. И там еще хуже - если установлен родитель для QWidget, то нельзя установить родителя для QObject, от которого он наследует (если бы можно было, я бы выкрутился).

Просьба не продолжать вариант с множественным наследованием - в Qt это нереализуемо. Если бы было допустимо двойное наследование от QObject, я бы уже так и сделал.

Единственный вариант - специализированные шаблоны. Но прежде чем начинать чеканить плохо изученный металл, я хочу пообщаться с теми, кто так делал.

Можно попробовать сделать так (кстати, со множественным наследованием :) ):

C++ (Qt)
class Common
{
public:
    Common( QWidget *w ) : m_w( w ) {}
 
    // Описываем общие методы для всех виджетов
    void func1()
    {
        m_w->setSize( 100500 );
    }
 
private:
    QWidget *m_w;
};
 
class MyLineEdit : public QLineEdit, public Common
{
    Q_OBJECT
public:
    MyLineEdit( QWidget *parent ) : QLineEdit( parent ), Common( this ) {}
 
    void method()
    {
        func1();      // Используем общие методы из Common
    }
};
 
 

Ну если единственный, т.е. Вы уже все решили - зачем нужно еще какое-то общение? :) Конкретно для Qt контролов не делал, поэтому в первую очередь проверил бы нет ли там засады с Q_OBJECT т.е. можно ли так

C++ (Qt)
template <class T>
class MyBaseWidget <T> : public T {
 Q_OBJECT
...
};

Без множественного наследования от QObject.


Сейчас именно так и сделано для отладки кода общих методов. Но беда в том, что большинство методов, которые общие для всех расширенных контролов - сигналы или слоты. Так у меня дизайн сделан, и это нельзя изменить. Причём у всех контролов они одинаковые. Фактически в класс Common получилось вынести только обработку событий мыши. И то не роскошно - события то принимать надо в классе MyLineEdit из примера. А в режиме нормальной работы контролов необходимо вызывать методы приёмников у родительского класса. В общем, пришлось пока объявить typedef-ом общий SuperClass, который должен быть классом контрола, то есть typedef QLineEdit SuperClass, и вызывать SuperClass::mousePressEvent(event) когда надо, чтобы кнопка нажималась, или строка редактировалась. Но это всё, включая ваш пример, не отменило необходимости копировать все методы, которые являются сигналами или слотами. Поскольку Common - не QObject...

Вот я об этом и спрашиваю - работал ли кто-либо с таким вариантом. Мне это может сэкономить день (с учетом поиска вариантов обхода, которых может быть и не существует), а отвечающему - занять несколько минут.

Это не работает с moc.

Пытались люди использовать шаблоны с QObject'ом.

Ничего кроме крови пота и боли они не получили. Но попробуйте, вдруг у вас получится :)

Да, пропатчить moc, чтобы он находил по коду проекта все инстанцинации шаблонов таких классов и генерил для каждого соответственный метаобъектный код. ;D

Тела слотов можно выносить в функции common, а в самих слотах вызывать эти функции.
Кстати, в Qt5 можно не объявлять методы слотами, использовать новый вариант connect.

Смысла особого нет, поскольку тела слотов из 2-3 строк.

Но еще можно мега-макрос написать... наверно я так и сделаю, если есть проблемы с шаблонами и Q_OBJECT.


На 4.7 делается.

Так ведь и другие (включая меня) думают так же: "та оно мне надо чего-то "изыскивать", экспериментировать? Вот найти пример и сделать по образцу - то да". Qt очень поощряет такой потребительский подход, ведь практически он очень эффективен. Почему-то вспоминается "Незнайка на Луне" как они там в конце все собирались строить лодку чтобы бежать с острова  :)

Ну ладно, не проходит так не проходит. Тогда может быть так

C++ (Qt)
class MyLineEdit : public QLineEdit {
 Q_OBJECT
public:
  MyLineEdit( QWidget * parent ):
 
#include MySlotSignals.h 
};

Так придется написать для каждого базового контрола - ну не беда, это всего неск строк. А в MySlotSignals рисуете общие слоты-сигналы. Если надо перенаправляете их на чистые виртуалы. И тогда уже

C++ (Qt)
template <class T>
class MyControl <T> : public T {
..
};
 

Но тут нет общего базового класса выше QWidget. Напр

C++ (Qt)
MyControl <MyLineEdit> * cnt1 = new...
MyControl <MyTextEdit> * cnt2 = new ...

Можно пользоваться только методами QWidget - и все.

Грубо, безобразно, хак - но так работает. Так я вообще с первого раза сделал, еще до своего первого поста в этой ветке. Просто не стал тут грубить. Даже шаблоны не нужны - просто в инклюд улетел добрый кусок класса контрола, вместе с методами получения событий мыши. В результате, например, объявление класса кнопки стало выглядеть вот так:


PluginInterface тут, поскольку каждый контрол сидит в Qt-плагине

Почему бы вместо typedef и include не обернуть общий функционал в макрос по аналогии с макросами Qt? Будет легче понять, что происходит.
Это в принципе не особо и хак, просто workaround для MOC.

C++ (Qt)
#include "common_controls.h"
#include <QPushButton>
 
class WButton : public QPushButton, public PluginInterface
{
    Q_OBJECT
    Q_INTERFACES( PluginInterface )
    COMMON_CONTROL(QPushButton)
public:
    ...
}
 
// common_controls.h:
 
#define  COMMON_CONTROL(BaseClass) \
signals: \
    void mySignal(); \
\
public slots: \
    void someSlot() \
    { \
        ##BaseClass::bla(); \
    }
 

Потому что такие макросы практически невозможно отлаживать. GDB и QtCreator на них колдобятся. В случае инклюда и точки останова работают, и переменные можно просматривать. И не надо каждый раз при добавлении или удалении qDebig() чего-то добавлять или удалять. И вообще править такие макросы неудобно (я в других местах использовал, наплевался уже).

А функционально результат почти не отличается, даже хуже - надо в двух местах родительский класс контрола указывать, можно ошибиться.

С отладкой да, есть недостаток.
Ну а что если вместо наследования использовать агрегирование (навроде pimpl)?

C++ (Qt)
#define COMMON_CONTROL(BaseClass, DerivedClass) \
private:                                        \
    friend class Impl<BaseClass, DerivedClass>; \
    Impl<BaseClass, DerivedClass> *commonImpl;  \
    void initCommonImpl()                       \
    {                                           \
        commonImpl = new Impl<BaseClass, DerivedClass>(this); \
    }                                           \
signals:                                        \
    void mySignal();                            \
                                                \
public slots:                                   \
    void mySlot()                               \
    {                                           \
        commonImpl->mySlot();                   \
    }
 
 
template<typename Base, typename Derived>
class Impl
{
public:
    Impl(Derived *parent): m_parent(parent) {}
    virtual ~Impl() {}
 
    void mySlot()
    {
        reinterpret_cast<Base*>(m_parent)->mySlot();
    }
 
private:
    Derived *m_parent;
};
 
class WButton: public QPushButton, public PluginInterface
{
    Q_OBJECT
    Q_INTERFACES( PluginInterface )
    COMMON_CONTROL(QPushButton, WButton)
public:
   WButton() { initCommonImpl(); }
};
 

+ не забыть удалить commonImpl (можно обернуть в умный указатель).

А это уже в гамаке и стоя, при том, что преимуществ не видно.

pimpl для того чтобы расписывать "для каждого", а здесь наоборот, нужно "для всех" (общая часть)

А ведь совсем недавно Вы весьма уверенно утверждали что специализация - единственный выход. Вероятно Вы хотели подтолкнуть обсуждение в нужном направлении, но все-таки обманывать нехорошо. Выходит Вам нельзя верить  :)

Я не вижу ничего страшного в таком инклуде, но вот если они начнут "расползаться", т.е. если их появится 2 и больше - тогда хана. Это может случиться если понадобится метод(ы) базового контрола которых нет у других, или наоборот. Напр setValue для QLineEdit. Тогда все-таки придется нырять в шаблоны. Ну а если такой проблемы нет, то и слава богу, меньше template-гадости = лучше  

Это смотря где ты ищешь преимущества. По мне преимущество только архитектурное: хоть какая-то инкапсуляция и возможность расширения (не факт, что ей придется воспользоваться); но писанины больше. include внутри класса - явный хак. Вообще, мне кажется, наследование здесь не лучший вариант, возможно с отдельным классом получится удачнее. Но хозяин-барин, решать все-равно тебе.


Поэтому и добавил "навроде". pimpl  упомянут только чтобы показать направление реализации.

Поясню проблему как я ее понимаю (а ТС если надо поправит). Напрашивается так
Здесь мы можем получить виджет имея Common, но "не наоборот". Пример: вызван слот QLineEdit'а, как Common может на это среагировать? Никак, потому что QLineEdit "не наш". Придется в Common делать членом указатель на QObject, мапировать сигналы QLineEdit на него и там уже вызывать обработчик Common. Ну это какая-то каракатица  :'(

Часто (и в этом топике) звучит, мол, "ах, вот если бы поддерживалось множественное наследование от QObject...". - тогда и проблем бы никаких не было. Не вижу что это особо меняет. Ну хорошо, допустим Common унаследован от QObject (предположим так можно). И что с того? Сигнал-то получает QLineEdit - а совсем не Common, проблемы те же

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

Опять же не знаю, кто там наш/не наш. Предлагалось вынести в common код общих методов и вызывать его из слотов самого виджета:

C++ (Qt)
class MyLineEdit : public QLineEdit, public Common
{
public:
    ...
 
private slots:
    void    onTextChanged( const QString &val )
    {
        commonMethodText( val );
    }
 
    void    onReturnPressed()
    {
        commonMethodReturn();
    }
};
 

А эти слоты можно попробовать завернуть в макросы.

Не выход, а вариант. По вопросам веры надо идти в церковь. Вариант с инклюдом я не считал, и не считаю приемлемым вариантом решения, даже при том, что он фактически наиболее простой и работающий. Во-1ых, может потребоваться наличие общих слотов/сигналов для нескольких контролов, но не для всех (хотя это тоже с помощью инклюда делается...). Во-2ых, может потребоваться наследование от имеющихся контролов.

Делал так. Не имеет смысла, поскольку "commonMethodText( val )" и "commonMethodReturn();" сами состоят из 1-3-х строк, а весь кусок private slots всё равно надо копировать. Или заворачивать в многострочный макрос (тоже делал) - но тогда отлаживать нормально не получается.

В варианте агрегирования не удаётся избавиться от копирования одинаковых методов в реализациях. Только вместо обработки сигналов, эти методы занимаются передачей сигналов для обработки. См. выше пример от Old.

В варианте инклюда общий класс у контролов вообще исчез.

Преимущества, которые для меня важны - упрощение и уменьшение кода, упрощение его модификации, возможность отладки. С расширением пока не ясно...

Я в этом сильно сомневаюсь

В чем именно?

В том что это решается (еще одним) инклудом. Станет их хотя бы 2 - пиши пропало

Страшного ничего при этом не наступает, хотя конечно - это тоже хак (to hack - англ. рубить). То есть, топором...

Думаю лучше запастись всеми нужными методами в wcontrol.h и дальше уже специализировать шаблонами.

Какой путь избрали?

#include "wcontrol.h"