Re: [Qemu-devel] [RFC] QDev explicit constructors & destructors

[Liviu Ionescu]

> On 15 Jun 2015, at 13:48, Liviu Ionescu <address@hidden> wrote:
> 
> ... One natural solution would be to add an explicit constructor, like in 
> C++. 

if this solution is considered too complicated, it might also be possible to 
arrange for the constructor data to be passed to the existing .instance_init 
call.

the use case would be even simpler:

  DeviceState *mcu = qdev_create_with_data(NULL, TYPE_STM32F103RB, 
&constructor_data);
  {
      /* Set various properties. */
      qdev_prop_set_uint32(mcu, "hse-freq-hz", 8000000); /* 8.0 MHz */
      qdev_prop_set_uint32(mcu, "lse-freq-hz", 32768); /* 32 KHz */
  }
  qdev_realize(mcu); /* QDev specific step */

the implementation requires the addition of a new member to the Object 
structure (for example .initialize_data), that must be set by 
object_initialize_with_type() before calling object_init_with_type().


the existing .instace_init callbacks need not be modified, the prototype can be 
kept as it is now.

new classes, that requires configuration data during construction, could simply 
read the pointer to the constructor data from this Object initialize_data field.

one advantage would be that the possible inconsistency between the moment the 
object is allocated and constructed by the explicit constructor would be 
avoided.

one disadvantage would be that the construction params could no longer be 
passed via properties, but only via the constructor structure (which shouldn't 
be a major problem).

another disadvantage, also present in the single pointer explicit constructor, 
is the fact that the constructor structure is the same for the entire hierarchy 
construction;

for example it would not be possible to have such hierarchies:

class Base {
public:
        Base(int param) {};
        ...
}

class Derived {
public:
        Derived(int param) : Base(param+1) {...};
        ...
}

or

class Derived2 {
public:
        Derived2() : Base(7) {};
        ...
}

these kind of construction policies can be achieved only with custom 
constructor callbacks, added to each class structure, and explicit chained 
calls issued by the user.

I currently use exactly this kind of custom calls in my code. (this is another 
alternate solution for this problem, do nothing in the framework and defer 
everything to the user).


of course, any other better ideas would be highly appreciated.


regards,

Liviu