On 02/22/2012 12:56 PM, Michael Meeks wrote:
So - the question would be then, how much of UNO is usable via the
in-line C wrappers ? I was under the impression that lots of it should
be - but perhaps I'm in cloud cuckoo land ;-)
With "in-line C wrappers" you mean the inline C++ code in exported headers of sal etc., right? That's enough to re-use the fundamental helper functionality for C/C++ UNO, so to speak, but it does not allow you at all to interact with UNO entities at the "UNO level," so to speak (i.e., call methods of UNO objects etc.).
I suppose, the vtable mismatch would need bridging between mingw and
msvc - which would be quite fun I suppose. Ho hum, as you say it's not a
wonderful idea - though having that bridging in place might be nice for
flexibility in future wrt. mingw cross-compile vs. MSVC building :-)
In principle, it should work to combine in a single process the UNO bridges for MSVC-ABI C++ UNO and GCC-ABI C++ UNO, and entities from the two worlds could then communicate transparently via UNO (going via the binary UNO hub, which is the common endpoint of the two different C++ bridges). All the URE libraries that are specific to a given C++ ABI would be loaded into the process in two versions (note that all those libraries contain the identifier for the C++ ABI in their names).
In practice, the (slightly?) tricky parts would be (a) to see that it really works to combine two C++ UNO bridges in one process---nobody has ever tried that AFAIK, and (b) to provide a LO installation set that contains the C++ ABI specific URE parts in both versions.
Stephan