I need to better understand our css::uno::Reference

[Stephan Bergmann]

On 06/24/2014 04:23 AM, Lionel Elie Mamane wrote:
> On Mon, Jun 23, 2014 at 01:07:14PM +0200, Stephan Bergmann wrote:
>> The trick is that we know that all compilers lay out the vtables in
>> roughly the same way: No matter how many types a given type X
>> derives from, a pointer to X points to a vtable containing function
>> pointers for X's first base (if any) followed by function pointers
>> for X's own members (if any).
>
> Aren't we missing X's other bases here? There needs to be function
> pointers for these, too, somewhere in the vtable. (I also understand
> that changing the order of derivation changes the ABI.) I "guess" the
> vtable is actually a depth-first left-to-right walk of the inheritance
> graph.

X's other bases are of no interest here, as all we need is access to 
(one of its potentially many) XInterface vtables (of which there may be 
many different instances, but which necessarily all contain the same 
function pointers).

(And your guess regarding vtable layout isn't quite right---a 
multiple-inheritance object has multiple vtables, one for each direct 
base subobject, where the derived class shares its vtable with its first 
direct base subobject at offset 0.  At least that's how the Itanium ABI 
does it.)

>> So as long as X represents any UNO interface type, the
>> css::uno::Reference<X> ctor can do that dirty trick of reinterpret-casting
>> pInterface to css::uno::XInterface* (...)
>
>> Now, if you break the assumption that X represents a UNO interface type,
>> that reinterpret_cast trick potentially breaks down.
>
> Do I understand right that:
>
> 1) UNO interface types are "carefully translated" to C++ so that
>     (one of the multiple) css::uno::XInterface is always the first
>     "ultimate base", so that its function pointers are always the first
>     in the vtable. This is what makes the reinterpret_cast trick work.

yes

> 2) UNO interface types don't use virtual inheritance, but the C++
>     objects that implement them typically do, at least for the class
>     that implements XInterface, and this is what ensures that all ways
>     to call ->acquire do use the same reference counters.
>
>     Or they carefully inherit only from one such XInterface
>     implementation...

no, neither interface nor implementation types use virtual inheritance 
(and both potentially inherit XInterface multiple times); what 
disambiguates a css::uno::Reference's call to acquire is the hack 
discussed previously; what disambiguates a rtl::Reference's call to 
acquire is its override in cppu::WeakImplHelperN (or a similar override 
for classes not deriving from cppu::WeakImplHelperN but deriving from 
XInterface more than once)

> 3) The UNO interface types are (purely) abstract (all their methods
>     are " = 0;" in the class definition), but this has nothing to do
>     with the discussed problem. This does not change the vtable
>     layout.

yes

Stephan