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.