Andrew Stitcher wrote:
On Tue, 2008-06-03 at 11:54 -0400, Alan Conway wrote:
...
gcc and solaris are differing on the rules about casting to private bases. I'm
not certain if it's tecnically incorrect but a bit of googling strongly suggests
that we should not write code that depends on this, we will probably have
trouble with other compilers.
I think we need to make the inheritance public, or come up with an alternative
design that does not require a dynamic_cast to a private base class.
I haven't done the googling, but it seems to be that statically I've got
a PollerHandle that as far as the code concerned knows came from a
DispatchHandle as far as this code is concerned there is no AsynchIO
involved at all. Locally there is no knowledge that private inheritance
is involved and there is none along the inheritance line that we are
casting up either. As private inheritance isn't between the PollerHandle
and the DispatchHandle I can't see why the dynamic_cast shouldn't
succeed. If I'd tried to cast to AsynchIO that should have failed.
One plausible implementation of dynamic cast is to first go to the most-derived
base class of the runtime object and then see if it is legal to statically
convert that to the requested type. In our case the most derived class is
AsyncIO and it is *not* legal to convert AsyncIO* to DispatchHandler* because of
inheritance.
Robs Microsoft link cites MS adding extra run-time checks to disallow
dynamic_casts involving private inheritance and I found a comp.std.c++
discussion of a similar (not identical) issue that.
I do not know what the correct interpretation of the C++ specification is here
but given that we have an actual divergence on two mainstream compilers and
other commentary which suggests this area is confusing for C++ implementors I
would strongly suggest that we simply avoid mixing private inheritance and
dynamic casting.
Andrew - is there any reason not to just make the inheritance public?
The only reason is clear design intent an AsynchIO object is not a
DispatchHandle object so to use public inheritance would be lying about
the relationship between the objects.
Private inheritance is just an attempt to hide the lie, the sun compiler is able
to uncover it ;) Can it be a member relationship instead of private inheritance?
