[Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

Dominik Haumann dhaumann at kde.org
Thu Mar 3 14:05:18 CET 2016


Hi Milian,
On Thu, Feb 25, 2016 at 7:22 PM, Milian Wolff <milian.wolff at kdab.com> wrote:
> On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
>> On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote:
>> > This might be a burden for some of the Qt developers (Windows ones).
>> >
>> > But all the Qt users get a modern / flexible moc, see this thread:
>> > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e
>>
>> I don't think we need a more flexible moc. What do we want to do that we
>> can't do with the current one?
>>
>> Don't say "template QObjects". That has other reasons for being a bad idea,
>> currently.
>
> Can you explain what those reasons are? I'd really love to write a generic
> QAbstractTableModel implementation that operates using concepts. Currently
> that would require type erasure and thus another set of virtual function
> calls...
> [...]
> If we'd have templates QObjects, the above could easily be written. I bet
> there are other valid use-cases.

It's not directly related, but instead of templated QObjects you
could also find worksarounds like this:
template <typename T>
class Foo {
public:
    // ...
    QObject * notificationObject();
private:
    QObject * m_notificationObject;
};

In the constructor, you can create the m_notificationObject
and even to connects etc.

I once used this trick (in a non-templated version) to obtain
value-semantics for a class that can still have signals and
slots etc (be careful with assignment operator, though).
Of course, you still might not have the metadata moc
typically creates for you. So I'm not claiming this is a
totally cool solution, but sometimes this workaround
comes in very handy.

Cheers,
Dominik



More information about the Development mailing list