From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-11-14 07:40:47
Vladimir Prus wrote:
> I'm just trying to find out why void_cast tests fail on gcc 3.3. Could you
> answer two quick questions:
> 1. Why void_cast is needed in the first place. It's hard to debug it
> without fully understanding the purpose.
Okay, more feedback. I think I've tracked down the problem.
The 'void_cast' function uses extended_typeinfo to store (from_type,to_type)
pairs in a set. The extended_type_info::operator<
uses type_info_key_cmp. The latter compare extended_type_info.type_info_key.
Now, for *all* instances of extended_type_info_typeid -- which is the type
which seems to be actually used, the value of 'type_info_key' is the same
(in particual because it's static member).
As the result, all extended_type_info_typeid instances are considered equal,
so it's not possible to distinguish conversion from type A to type B from
conversion from type C to type D. Looks like it's the reason for test
failure for me.
void_cast is called to convert MostDerived to Base1, it find transformation
via intermediate derived and stores it. After that, conversion from
MostDerived to Base2 is requested. void_cast picks the caster for
MostDerived->Base1 case an uses that. No wonder that the result is
incorrect. Am I right in thinking that this is serious bug with void_cast?
Another, unrelated comment. If void_cast can't find direction transformation
it tries intermediate types with:
for ( it = global_registry().m_set.begin();
it != global_registry().m_set.end();
I.e. it considers *all* knows types. Is this behaviour really desired? Can't
be just consider all transformation for the current from_type?
The last remark. I'd really appreciate much more comments in the code. As it
stands now, I have big problems understanding the code, not to mention the
motivation for why the code is written the way it is.
For example, class 'exended_type_info' has no explanation why it's needed.
The 'extended_type_info.type_info_key' has comment which tells what for the
variable is used, but I'd rather prefer a comment which tells what this
member variable *is*, what are valid values, and so on.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk