Stephan Bergmann wrote:
Stephan Bergmann wrote:
Jürgen Schmidt wrote:
Frank Schönheit wrote:
[...]
So, the question remains: Is it feasible to do what Jörg suggested:
Extend cppumaker so it disambiugates methods of interfaces which are
inherited indirectly multiple times? E.g., let cppumaker generate
class XFormControlModel
: public XUnoControlModel, public XFormComponent2
{
...
// disambiguate XPropertySet
// inherited from both XUnoControlModel and XFormComponent2
virtual Reference< XPropertySetInfo > SAL_CALL
getPropertySetInfo( )
throw (RuntimeException) = 0;
virtual void SAL_CALL setPropertyValue(...) throw(...) = 0;
virtual Any SAL_CALL getPropertyValue(...) throw(...) = 0;
...
};
needs to be evaluated ...
sounds good
[...]
The problem with this approach is that it changes the vtable layout for
some compilers (GCC and the Solaris compiler seem to be affected), so
that the cpp_uno bridges would have to be adapted on those platforms,
which has two drawbacks:
For one, this would be an incompatible change (however, there currently
is only one affected interface in the OOo UNO API,
com.sun.star.xforms.XDataTypeRepository, which is unpublished). For
another, it would increase the (time and code) complexity of cpp_uno and
cppumaker, would make cpp_uno depend on compiler details even more than
it already does.
Thinking a bit more about the problem, there appear to be four options:
1 Leave everything as is and force C++ client code to do the
disambiguation.
2 Make the changes proposed above, ignore the potential
incompatibility, and extend the cpp_uno bridges.
3 Instead of adding pure virtual disambiguating functions as proposed
above, add specially-named non-virtual inline functions to the
cppumaker-generated classes, like
class XFormControlModel: ... {
...
inline Reference<XPropertySetInfo> call_getPropertySetInfo() {
return static_cast<XUnoControlModel*>(this)->getPropertySetInfo();
}
...
};
That way, the cpp_uno bridges (and the service implementations) are not
affected, only client code needs to change getPropertySetInfo to
call_getPropertySetInfo in case of an ambiguity (which the compiler will
flag).
4 Make the cut and change the C++ UNO language binding in an
incompatible way by using virtual inheritance for interfaces. Ideally,
this would only be incompatible in that C++ code has to be recompiled,
but nothing else changes. It might be worthwhile to think this through
further (potentially identifying other areas that could be improved when
taking this---significant---step).
I would prefer the 4th option because it would be exactly that what we
want and for the long run it would be the clean one. Everything else is
to work around this problem which could be solved in a clean way with
this build compatible change (hopefully only). 1-3 make the UNO
programming not even more intuitive and is one more specialty which the
user have to learn, needs to be documented ...
Ok, we would break our binary compatibility promise but i think it would
be the right decision even when we check further improvements as Stephan
has mentioned.
C++ UNO extensions need to be rebuild then for the next version but that
can be happen also when we change the compiler (not necessarily but
possible)
Juergen
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
