Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.