[Interest] How to create QObject-derived class instance from class name

[Sina Dogru]

Ah you mean by "knowing types at compile time" is actually defined types,
so you actually defining classes at run-time?

2016-03-02 13:04 GMT+02:00 Nye <kshegunov at gmail.com>:

> I just meant that in my case the classes are defined in the user
> application, so the library has no notion whatsoever what classes it has
> available to create instances from and it depends on the meta-type system
> exclusively for that (while still handling the
> serialization/deserialization of said instances). It just makes a factory
> inapplicable in my case (at least if you're not counting the meta-type
> system as a factory).
>
>
> On Wed, Mar 2, 2016 at 12:58 PM, André Somers <andre at familiesomers.nl>
> wrote:
>
>>
>>
>> Op 02/03/2016 om 11:51 schreef Sina Dogru:
>>
>> > For now there is a design choice which I feel weak myself, to do
>>> factory or to use QMetaType for creating instances.
>>>
>>> Depends on the use case I suppose. If you know the types at compile
>>> time, as is usually the case I'd go with the simple solution to make a
>>> factory. I recently, however, had a case where the deserialization routine
>>> couldn't know at compile time the exact type (i.e. for a library), so I had
>>> to put a (gadget) base class and use the runtime type ids.
>>>
>>
>> Since I'm trying to recover states of the QObject-derived class instances
>> from a file, it is not possible to know the types at compile time. But is
>> not that factory was also for creating objects that type is known at
>> run-time? Or am I missing something? Because I thought both factory and
>> metaobject system provide run-time object creation?
>>
>> You are right. If you know the type you need at compile time, just
>> construct the instance directly.
>> Factories are useful for the creation of objects who's types you do _not_
>> know at compile time. And indeed, as demonstrated above, the metaobject
>> system together with the metatype system can also be abused to do the same
>> thing.
>>
>> André
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160302/f92a47cd/attachment.html>