[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