> > There is a declarative solution for this that I know of, a C++ class
> > definition ;-)
>
> So what's the reason not to go with one of the object-oriented,
> C-compatible languages GCC supports, like C++ or Objective-C/C++?
> (Objective-C has native reflection capabilities fwiw.)
I'd avoid Ob
On 01/25/2012 07:40 AM, Anthony Liguori wrote:
>>>
>>> (void *) isn't compatible with integers or function pointers (at least
>>> not in a portable way).
>
> I don't see how they can be compatible since on some platforms
> sizeof(void (*)(void)) != sizeof(void *).
C99 says they are not required t
Am 25.01.2012 15:40, schrieb Anthony Liguori:
> On 01/25/2012 08:23 AM, Jan Kiszka wrote:
>> On 2012-01-25 15:00, Anthony Liguori wrote:
>>> On 01/25/2012 02:37 AM, Jan Kiszka wrote:
On 2012-01-25 00:03, Anthony Liguori wrote:
> They're exactly the same size (16 lines). If you embed TypeI
On 01/25/2012 08:23 AM, Jan Kiszka wrote:
On 2012-01-25 15:00, Anthony Liguori wrote:
On 01/25/2012 02:37 AM, Jan Kiszka wrote:
On 2012-01-25 00:03, Anthony Liguori wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type
On 01/25/2012 02:33 AM, Andreas Färber wrote:
Am 25.01.2012 00:03, schrieb Anthony Liguori:
On 01/24/2012 04:06 PM, Jan Kiszka wrote:
On 2012-01-24 22:53, Anthony Liguori wrote:
But I don't like this. The problem is that the declarative syntax we
have doesn't distinguish between "not-specifie
On 2012-01-25 15:00, Anthony Liguori wrote:
> On 01/25/2012 02:37 AM, Jan Kiszka wrote:
>> On 2012-01-25 00:03, Anthony Liguori wrote:
>>> They're exactly the same size (16 lines). If you embed TypeInfo into
>>> DeviceTypeInfo, and introduce a Device specific type registration
>>> function, then y
On 01/25/2012 02:37 AM, Jan Kiszka wrote:
On 2012-01-25 00:03, Anthony Liguori wrote:
They're exactly the same size (16 lines). If you embed TypeInfo into
DeviceTypeInfo, and introduce a Device specific type registration
function, then you could do:
static DeviceTypeInfo my_device_type_info =
On 01/25/2012 10:33 AM, Andreas Färber wrote:
> >
> > There is a declarative solution for this that I know of, a C++ class
> > definition ;-)
>
> So what's the reason not to go with one of the object-oriented,
> C-compatible languages GCC supports, like C++ or Objective-C/C++?
> (Objective-C has n
On 01/25/2012 11:27 AM, Jan Kiszka wrote:
> I agree with Anthony, this would get really ugly where you are calling
> the functions and doing the class initialization.
I think we need to try it first.
There is a lot of repetition, and that gets boring at beat and ugly at
worst when doing it fo
On 2012-01-25 11:15, Paolo Bonzini wrote:
> On 01/25/2012 09:37 AM, Jan Kiszka wrote:
>>> > They're exactly the same size (16 lines). If you embed TypeInfo into
>>> > DeviceTypeInfo, and introduce a Device specific type registration
>>> > function, then you could do:
>>> >
>>> > static DeviceT
On 01/25/2012 09:37 AM, Jan Kiszka wrote:
> They're exactly the same size (16 lines). If you embed TypeInfo into
> DeviceTypeInfo, and introduce a Device specific type registration
> function, then you could do:
>
> static DeviceTypeInfo my_device_type_info = {
> .type.name = TYPE_MY_D
On 2012-01-25 00:03, Anthony Liguori wrote:
> They're exactly the same size (16 lines). If you embed TypeInfo into
> DeviceTypeInfo, and introduce a Device specific type registration
> function, then you could do:
>
> static DeviceTypeInfo my_device_type_info = {
> .type.name = TYPE_MY_DEVICE
Am 25.01.2012 00:03, schrieb Anthony Liguori:
> On 01/24/2012 04:06 PM, Jan Kiszka wrote:
>> On 2012-01-24 22:53, Anthony Liguori wrote:
>>> But I don't like this. The problem is that the declarative syntax we
>>> have doesn't distinguish between "not-specified" and
>>> "zero-initialized".
>>
>> T
On 01/24/2012 04:06 PM, Jan Kiszka wrote:
On 2012-01-24 22:53, Anthony Liguori wrote:
But I don't like this. The problem is that the declarative syntax we
have doesn't distinguish between "not-specified" and
"zero-initialized".
That's surely solvable.
Please try :-)
I've spent a good chunk
On 2012-01-24 22:53, Anthony Liguori wrote:
> On 01/24/2012 03:31 PM, Jan Kiszka wrote:
>> On 2012-01-24 22:11, Anthony Liguori wrote:
>>> On 01/24/2012 03:01 PM, Jan Kiszka wrote:
On 2012-01-24 21:21, Anthony Liguori wrote:
>> Also, I see a lot of programmatic initialization and a lot of
On 01/24/2012 03:31 PM, Jan Kiszka wrote:
On 2012-01-24 22:11, Anthony Liguori wrote:
On 01/24/2012 03:01 PM, Jan Kiszka wrote:
On 2012-01-24 21:21, Anthony Liguori wrote:
Also, I see a lot of programmatic initialization and a lot of repeating
patterns (specifically regarding trivial class ini
On 2012-01-24 22:11, Anthony Liguori wrote:
> On 01/24/2012 03:01 PM, Jan Kiszka wrote:
>> On 2012-01-24 21:21, Anthony Liguori wrote:
Also, I see a lot of programmatic initialization and a lot of repeating
patterns (specifically regarding trivial class initialization) - there
is no
On 01/24/2012 03:01 PM, Jan Kiszka wrote:
On 2012-01-24 21:21, Anthony Liguori wrote:
Also, I see a lot of programmatic initialization and a lot of repeating
patterns (specifically regarding trivial class initialization) - there
is no better alternative?
Not really, no. It looks bad now becau
On 2012-01-24 21:21, Anthony Liguori wrote:
>> Also, I see a lot of programmatic initialization and a lot of repeating
>> patterns (specifically regarding trivial class initialization) - there
>> is no better alternative?
>
> Not really, no. It looks bad now because you have DeviceInfo still.
>
On 01/24/2012 02:01 PM, Jan Kiszka wrote:
On 2012-01-24 20:33, Anthony Liguori wrote:
This converts three devices because apic and ioapic are subclasses of sysbus.
Converting subclasses independently of their base class is prohibitively hard.
Hmm, I think that's more than three... Can you spli
On 2012-01-24 20:33, Anthony Liguori wrote:
> This converts three devices because apic and ioapic are subclasses of sysbus.
> Converting subclasses independently of their base class is prohibitively hard.
Hmm, I think that's more than three... Can you split up? At least per
target or per board/mac
21 matches
Mail list logo
