[Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]
Thiago Macieira
thiago.macieira at intel.com
Sat Feb 27 09:19:17 CET 2016
On sábado, 27 de fevereiro de 2016 09:48:36 PST Marc Mutz wrote:
> On Saturday 27 February 2016 00:56:08 Thiago Macieira wrote:
> > Have I convinced you? I'm only getting warmed up. I'm sure I can find more
> > issues.
>
> That's all correct. But can't we create a subset of features that the
> QObject template may use in order to make that subset work?
I don't think so. The thing with currently no solution is the ability to add
mix templates and signals (signals in template class or template signals).
Without signals, it all breaks down.
> As for the staticMetaObject, moc could write its output not as C++ code,
> but as a macro containing the C++ code, for QObject templates, to be called
> with those QObject template instantiations that the user creates (similar
> to the old method of template instantiation where the user needs to list
> the explicit template instantiation in a separately-compiled TU). Only one
> TU would contain the macro call for any given instantiation, solving the
> multiple-definition problem you mentioned.
This would be severely limited, but doable. It would only work for a small,
hand-crafted list of template parameters and only if the template parameters
were used in very trivial uses, like these:
> template <typename T>
> class ListModel : QAbstractListModel {
> Q_OBJECT_TEMPLATE(T)
> public:
> // ...
adding:
Q_PROPERTY(T value READ value WRITE setValue)
signals:
void changed(const T &);
public slots:
void change(const T &t);
> };
>
> // in some other TU
But you can't do anything non-trivial with T, like use it in remove_cv<T>.
If we were to do this, I'd also require the list of explicit instantiations to
be in the header file. This serves two purposes:
a) it makes it clear to the user that only those instantiations are
permitted, and to the compiler that it should not instantiate on its own
b) it allows moc to know which instantiations to create a meta object for,
dispensing with the need for a macro. By doing this, moc-ng could even
deal with complex uses of the template parameters.
There's no solution for template members, though.
Is it worth it? How often are templates used with only a very small list of
explicit instantiations?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list