Andrew Stitcher escribió:
On Tue, 2008-06-03 at 13:51 +0200, Manuel Teira wrote:
...
It also works if I just change the inheritance AsynchIO ->
DispatchHandle to public.
Any idea about what could be happening?
It looks to me like either this is a bug in the Sun compiler or the gcc
one.
As in either the Sun compiler should be able to perform the conversion
even though there is private inheritance is involved. Or the gcc
compiler is allowing a conversion where it shouldn't.
Is there any possibility of using gcc for your compiles?
[Not that I'm trying to put you off the Sun compiler, but if gcc
works...]
Well, I would like to be able to use the Sun Compiler. I also think that
it would be good for the project.
I would like to understand where the problem is. So, please comment on
my (probably wrong) hypothesis:
We have the following inheritance chain:
AsynchIO: private DispatchHandle
DispatchHandle: public PollerHandle
So, AsynchIO is implemented in terms of DispatchHandle. In the method
AsynchIO::start(Poller::shared_ptr Poller), we have the call:
DispatchHandle::startWatch(poller);
And in DispatchHandle::startWatch(Poller::shared_ptr Poller), we
eventually call:
poller->addFd(*this, 0);
So, what can we say we are passing here as *this, a DispatchHandle
object, or a AsynchIO one?
If we inspect the argument inside the Poller::addFd(PollerHandle&
handle, Direction dir) method, what we see is an AsynchIO object, at
least that is what the typeid() is saying us. Even though the typeid()
on the *this pointer inside DispatchHandle::startWatch seems to be
identified as a DispatchHandle*.
My first doubt here is why what is identified as an AsynchIO inside the
Poller::addFd method, is actually being acepted as a PollerHandle&.
Shouldn't the private inheritance avoid it?
Because latter behaviour seems coherent to me, if the object is an
AsynchIO, we should never be able to convert it back again to a
DispatchHandle or a PollerHandle.
So, I think that the crux is: what a *this pointer inside a private
inherited class represents? Empirical tests based in the typeid output,
seems to say that it's seen as the outermost object, at least out of the
context of the private class itself. If this is true, it shouldn't be
licit to use it as the private class type, neither its base class.
Perhaps the bug is that the Sun compiler is allowing us to pass what is
identified as an AsynchIO reference into a method accepting a
PollerHandle one. Further transformation eventually fail, trying to
downcast from PollerHandle to DispatcherHandle. But is the g++ behaviour
acceptable?
Could be an aceptable workarround to use composition to bind AsynchIO to
DispatcherHandle instead of private inheritance? This should avoid the
problem, I think , but perhaps it's not conceptually valid.
Very confusing, isn't it?
Andrew
