Hello developers,
the msxml3 code currently uses aggregation to implement IXMLDOMNode on
all of the different DOM tree elements. As the interfaces for these
elements are all derived from IXMLDOMNode, a lot of forwarding thunks
have to be implemented to get the calls into the inner object. The
attached patch series modifies the source code to derive the objects
instead, which seems like the more natural approach to get derived
interfaces implemented.
The attached patches still have to be cleaned up: They contain lines
ending with whitespace, incosistent spacing around function call
parenthesis, incosistent style of using a cast helper function or direct
casting and other small nits.
A more important problem with these patches that make me write this mail
is that they generate lots of compiler warnings like
| domdoc.c:1556: warning: initialization from incompatible pointer type
which is of no surprise, as the vtable for domdoc expects a function
taking an IXMLDOMDocument as "this" pointer while I provide a function
taking an interface pointer to an IXMLDOMNode as "this" pointer. Both of
these pointers point to the same address (as usual for derived objects),
so the conversion is safe, but the simple-minded C compiler can't know
that.
The question that arises is how to handle these warnings.
a) ignore them (most probably not an option)
b) add lots of casts (only way to make the idea of these patches fly)
c) write lots of little forwarding functions that convert the this
pointer.
d) ditch the idea of using derivation instead of aggregation
Any oppions on that? I (obviously) think that b is the right solution,
but as a quick grep over the Wine source code revealed, this solution
seems to be used nowhere. Is that because this is the first place where
deriving makes sense or is that because I'm completely off-track?
Kind regards,
Michael Karcher
PS: The munged "From " lines in the attached patches are intentional.
They keep my email program from choosing "application/mbox" as MIME
type.