> On 14 Jun 2015, at 15:43, Liviu Ionescu wrote:
>
> in practical terms this means that realize() should be called right after
> creation, immediately after setting the properties:
>
> DeviceState *mcu = qdev_create(NULL, TYPE_STM32F103RB);
> {
> qdev_prop_set_uint32(mcu, "hse-freq-h
On Sun, Jun 14, 2015 at 11:47 AM, Liviu Ionescu wrote:
>
>> On 13 Jun 2015, at 12:29, Peter Crosthwaite
>> wrote:
>>
>> There is a way :). Check object_class_get_parent. qdev.c uses it to
>> implement device properties on multiple levels without overriding. You
>> still need to explicit call to
> On 13 Jun 2015, at 12:29, Peter Crosthwaite
> wrote:
>
> There is a way :). Check object_class_get_parent. qdev.c uses it to
> implement device properties on multiple levels without overriding. You
> still need to explicit call to superclass in each child class but that
> is normal of OO synt
> On 14 Jun 2015, at 04:49, Peter Crosthwaite
> wrote:
>
> ...
> The number of machine init args blew out of control at one stage so
> they were structified. It was natural to roll this struct into the
> machine-state struct.
can we have multiple machine instances simultaneously, each with its
> On 14 Jun 2015, at 15:43, Liviu Ionescu wrote:
>
>
>> I never said you cant ref one object from another. QOM links exist for
>> this exact purpose.
>
> Q: any example of QOM links?
ok, I found them, they are not part of qdev but only in qom.
they look like this:
object_property_set_l
> On 14 Jun 2015, at 04:49, Peter Crosthwaite
> wrote:
>
>
> ...
> Infact, I have an application of constructor arugments myself. This is
> for the ARM A9 MPCore container where the number of CPUs is variable
> per-instance. Same problem as you are facing, realize is too late,
> init is too ea
On Sat, Jun 13, 2015 at 5:56 PM, Liviu Ionescu wrote:
>
>> On 14 Jun 2015, at 01:46, Peter Crosthwaite
>> wrote:
>>
>>> not to mention that in real life situations, constructors are used to pass
>>> non-static data, for example the 'machine' structure (for various command
>>> line params) when
> On 14 Jun 2015, at 01:46, Peter Crosthwaite
> wrote:
>
>> not to mention that in real life situations, constructors are used to pass
>> non-static data, for example the 'machine' structure (for various command
>> line params) when constructing MCUs, or the 'mcu' when constructing LEDs.
>>
On Sat, Jun 13, 2015 at 11:57 AM, Liviu Ionescu wrote:
>
>> On 13 Jun 2015, at 21:29, Peter Crosthwaite
>> wrote:
>>
>>
>> ... As all the information
>> you need to construct the object is constant per-concrete class, the
>> information can be added to the class to resolve.
>
> the one-instance-
On Sat, Jun 13, 2015 at 12:52 PM, Liviu Ionescu wrote:
>
>> On 13 Jun 2015, at 21:57, Liviu Ionescu wrote:
>>
>> ... so, no, the class structure is not suitable for multi-instances objects,
>> and even for singletons I think that using it for passing such configuration
>> data is generally abus
> On 13 Jun 2015, at 21:57, Liviu Ionescu wrote:
>
> ... so, no, the class structure is not suitable for multi-instances objects,
> and even for singletons I think that using it for passing such configuration
> data is generally abusive.
not to mention that in real life situations, constructo
> On 13 Jun 2015, at 21:29, Peter Crosthwaite
> wrote:
>
>
> ... As all the information
> you need to construct the object is constant per-concrete class, the
> information can be added to the class to resolve.
the one-instance-per-class might be true for MCUs, but generally it isn't, for
ex
On Sat, Jun 13, 2015 at 4:41 AM, Liviu Ionescu wrote:
>
>> On 13 Jun 2015, at 12:29, Peter Crosthwaite
>> wrote:
>>
>>>
>>> STM32F103RB* mcu = new STM32F103RB(&stm32f103rb_capabilities);
>>>
>>
>> Is the capabilities genuinely variable from instance to instance?
>
> good point.
>
> my example wa
> On 13 Jun 2015, at 14:41, Liviu Ionescu wrote:
>
> ... so I invented another solution:
>
> - do not define any of the instance_init() and instance_post_init()
> - add custom construct(...) callbacks to all my classes
> - make each instance call parent construct(...) at the beginning, as for
> On 13 Jun 2015, at 12:29, Peter Crosthwaite
> wrote:
>
>>
>> STM32F103RB* mcu = new STM32F103RB(&stm32f103rb_capabilities);
>>
>
> Is the capabilities genuinely variable from instance to instance?
good point.
my example was not very accurate, the capabilities are indeed specific to a
c
On Fri, Jun 12, 2015 at 4:33 AM, Liviu Ionescu wrote:
> while implementing the cortex-m hierarchical objects I faced several problems
> that required some hack, and I wanted to know your comments on them.
>
> for convenience I'll explain the problem in C++ and then return to the issues
> of the
any object oriented gurus around?
regards,
Liviu
> On 12 Jun 2015, at 14:33, Liviu Ionescu wrote:
>
> while implementing the cortex-m hierarchical objects I faced several problems
> that required some hack, and I wanted to know your comments on them.
>
> for convenience I'll explain the pro
while implementing the cortex-m hierarchical objects I faced several problems
that required some hack, and I wanted to know your comments on them.
for convenience I'll explain the problem in C++ and then return to the issues
of the C implementation. (the C++ syntax may not be very strict).
one
18 matches
Mail list logo
