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

[Nye]

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/6385b20c/attachment.html>