qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup
Date: Mon, 23 Aug 2010 09:47:46 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

On 08/23/2010 09:32 AM, Avi Kivity wrote:
Is bad? The answer would depend on whether OtherState implemented methods or not. If OtherState has no methods, it's fine. If it has methods, it's bad.


I don't see why. As long as you can manipulate all of MyDevice's state via MyDeviceState methods, why do you care about OtherState at all?

See below.


Devices can contain references to structs and objects. If a Device contains a reference to an object, the object should be stored in a BusState which is a container of Devices. Therefore, the object should inherit from Device.

I disagree. It's up to the author to decide whether to split a Device into 1 or 15 objects.

If one of the other objects is also a subclass of DeviceState, then you're probably violating that DeviceState's contract. But that's a different (and trivial) matter.

(side point: in C no objects have constructors and methods. in C++ all objects have constructors and methods, even PODs)

Things that inherit from DeviceState have ctors/dtors. Things that don't end up inventing their own and probably will do so poorly.

When implementing a C object model, you really need to have a base object that everything inherits from. In glib, it's GObject.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]