On 8/14/15 11:39 AM, Timon Gehr wrote:
On 08/13/2015 06:05 PM, Steven Schveighoffer wrote:
On 8/13/15 11:59 AM, Steven Schveighoffer wrote:
That is definitely a bug. It's because typeid is looking up the derived
type via the vtable, but the compiler should rewrap it with 'shared'
afterwards.
Actually, now that I think about it, I'm not sure how the compiler can
figure this out.
There would have to be a way to construct a TypeInfo_Shared at runtime,
which the compiler shouldn't be doing. Alternatively, it could
proactively create a TypeInfo_Shared (and all the other flavors) for
each class type in the runtime, and then look it up using some hash
mechanism.
...
Can't the shared typeinfo be constructed for all superclasses of C at
the point where shared(C) is used? (Think: template instantiation.)
I don't think it can do this at compile time. It would have to do it at
link time, since it doesn't know what subclasses of C will exist. If
it's a dynamically-linked library, it would have to construct them on
library load.
Optionally, it could allocate the necessary TypeInfo_Shared on the heap
when needed. I don't like that idea either.
This likely isn't fixable.
...
I don't understand. It is evidently fixable. E.g. if TypeInfo was just a
template without the mostly redundant additional compiler support, this
would be a trivial fix.
I mean, it's not likely fixable without a drastic redesign of the
typeinfo system. I'd prefer having typeinfo simply not exist as far as
the compiler is concerned, and have typeid call a template with the type
as the parameter. We have RTInfo, we should make the whole darned thing
done that way.
-Steve
