Hi Jacek.
Hi Michael,
Casting function in vtbl is not an acceptable solution. If you have to do that, it means that the design is bad.
So in short that means that using deriving for objects to implement derived interfaces is not possible in Wine, as it is not cleanly implementable in plain C. Too bad, but I also don't like casts in the vtbl, as they are definitely not typesafe. I think one could come up with a preprocessor macro hack that enforces typesafety and results in plain casts, but macro-magic is rightly frowned upon in wine. I don't think anyone would like to maintain the macro-mess that would be needed (including myself).
Any oppions on that?
I think other solution would be better. There is no reason for xmlnode object to implement any interface.
xmlnode could provide a default implementation for most of the functions, so one only has to override the functions that need specific handling. If derivation could be used, one does not have to write tons of separate stubs that just do the same, namely forward calls to the xmlnode default handlers (I would call that poor man's derivation), which would kill a lot of boilerplate source code, and thus reduce executable size (who needs 300[1] functions containing [if gcc optimizes correctly, not verified] just one jump instruction if the address of the target could have been put instead in the vtable) and improve performance a bit. On the other hand, 300 jumps instructions (if the optimizer works...) are just 1.5 kilobytes, and that shouldn't hurt that much on modern computers.
[1] order-of-magnitude estimate.
All its child objects already have IXMLDOMNode interface.
Yes, of course, as the child objects implement interfaces that are derived from IXMLDOMNode (either directly or indirectly).
xmlnode could be a common struct stored by child objects and there could be set of function with common method implementation.
Right. That is quite like the direction I was also heading to. The extra memory allocation and use of COM aggregation for the xmlnode object definitely seems like overkill, and is also avoided by the containment approach you suggest.
This way we could also avoid ugly tests for node type in node.c, because we can handle the difference outside node.c.
Very good point, didn't take a look at them. These tests should get expunged and replaced by different implementation chosen by the vtable of the IXMLDOMFoo imlementing objects.
Thanks for your input, Michael Karcher