On 3/5/21 1:02 PM, Jacek Caban wrote:
On 05.03.2021 17:21, Zebediah Figura (she/her) wrote:
Static object also don't really need a structs like windows_media_speech, but it's fine to have it. However, IVectorView_VoiceInformation doesn't really belong to windows_media_speech object as it looks like a separate object.
As far as I can tell, it's not a mutable interface and therefore doesn't need to be made into a separate object, right?
I assume that by separated object you mean separated C structs to represent multiple COM objects. If we have separated QueryInterface implementations, then we deal with separated COM objects even if they are represented by a single C struct (and share ref count, which is not great).
And yes, technically it doesn't need to be a separated struct, but when I look at something like that:
struct windows_media_speech
{ IActivationFactory IActivationFactory_iface; IInstalledVoicesStatic IInstalledVoicesStatic_iface; IVectorView_VoiceInformation IVectorView_VoiceInformation_iface; LONG ref; };
the first (and usually right) impression is that it's an object that implements 3 interfaces (as in, any of its QueryInterfaces will support all those interfaces). And yet in this case it's not true. I'd really need to read all QueryInterface implementations to learn that it's really a struct representing two separated COM object. It could be clarified with a comment, but I don't really see why in this particular case we'd want a single struct at all. It doesn't seem to be making anything easier. There are cases when something like that may be useful, but this one doesn't seem one of them.
Well, it's one less allocation, which is always nice.
Definitely the interface should be visually separated in the windows_media_speech structure, though.
BTW, as long as those object implement ref counting, they are not exactly immutable.
True, but I at least hope we're past the point where programs abuse COM refcounting all the time, and that nonsense can be confined to things like ddraw and dmusic ;-)
Jacek