[Development] Container refactor update

Peter Kümmel syntheticpp at gmx.net
Tue Jun 19 11:46:13 CEST 2012


On 19.06.2012 11:04, Olivier Goffart wrote:
> On Tuesday 19 June 2012 10:22:02 Peter Kümmel wrote:
>> On 19.06.2012 10:00, Thiago Macieira wrote:
>>> On terça-feira, 19 de junho de 2012 09.51.32, Peter Kümmel wrote:
>>>> On 19.06.2012 09:11, Rene Jensen wrote:
>>>>> Is this crazy talk? I would imagine that given a set of containers like
>>>>> ... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject
>>>>> (yes, I know ... moc and templates bla bla - I could live with fixed
>>>>> key/value-types if that's what it takes - java did before going
>>>>> parametric),
>>>>
>>>> Maybe there's a time moc embeds clang and can 'understand' template code.
>>>
>>> Moc can understand template code just fine for the output it produces. The
>>> problem is that the meta object format does not allow for signals and
>>> slots
>>> containing template parameters in their signature.
>>
>> But moc could not produce code like this, so I would say it is not "just
>> fine":
>
> moc needs small adaptations, that's true. But here your example involve
> specialisation of template, which i think is another level.
>
>
>
> What would be possible with some addapation is
>
> template<typename T>  class A : public QObject { Q_OBJECT
>     signal: void someSignal(T);
> };
> ///
>
> Then moc should basically be adjusted to generate what it generates now, but
> adding  template<typename T>  in front of everything, and some other small
> adjustemnt
>
>
> template<typename T>  QMetaObject A<T>::staticMetaObject = { ... };
>
> template<typename T>  void A<T>::someSignal() {
>    QMetaObject::activate(this, staticMetaObject, 0);  }
>
> template<typename T>  void A<T>::qt_metacall(...) {
>   ...
>   case 0: someSignal(*reinterpret_cast<T*>(*args[1]))
> }
>
>
>
> Not very complicated, but the other point is that then one should include the
> moc everywhere.
> And is it really worth it?

To make QObject THE base class within a framework it is necessary I think.


>
>



More information about the Development mailing list