Re: [cxx-abi-dev] trivial __dynamic_cast fails?

[Nathan Sidwell <nathan@xxxxxxxxxxxxxxxx>]

David Abrahams wrote:

> I think it's probably more widely neededthan you'd guess, at the
> boundary between statically and dynamically-typed systems.  I doubt
> anyone else has had the insanity to try to simulate it in conforming
> code, or the wherewithal to express to implementors what they were
> trying to achieve, so most people who might've needed it probably just
> gave up.  That's a long-winded way of saying this is the first time
> I've ever heard that someone else besides me wanted it.  If it's
> (almost) in cxx abi v1, and David B. wants it, and I want it, it seems
> like a few people at least have decided it's important.
One of the design goals of the __dynamic_cast API was to optimize the
the time of the call -- in either producing a pointer to the target
object, or NULL.  Therefore it should do the minimal tree walking
to acheive that.  As dynamic casting needs to know whether it met
the staticly typed object started from, it checks this and does not
walk into that subtree. Hence the behaviour you have observed.

We should not change the functionality of __dynamic_cast without
also augmenting its API, so that we can maintain the above behaviour.

One solution would be to allow NULL as the typeid of the static
starting base.  In the cases shown, I believe this is what you want. The
question you are asking is
  given this complete type of dynamic type, find the unambiguous public
  base of dynamicly determined type Foo.
(By dynamically determined, I mean the compiler has no knowledge of the
typeid that will be passed in -- because it's been squirrelled away by
some other bit of code.) In fact I think the current GCC implementation
will DWYW if you pass some unrelated third typeid as the static starting
type.

If the question you are asking is
  given this complete type of dynamic type, find the unambigous public
  dynamically determined base Baz and then find the unambigous public
  dynamically determined base Foo of that intermediate base
another solution is needed.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@xxxxxxxxxxxxxxxx    ::     http://www.planetfall.pwp.blueyonder.co.uk