Re: [boost] yet another multimethods library (need a hand here)

From: Korcan Hussein (korcan_h_at_[hidden])
Date: 2006-03-08 13:33:28

> "Joaquín Mª López Muñoz" <joaquin_at_[hidden]> wrote in message
> news:440D86A5.532D8066_at_tid.es...
>
> I don't know what you mean here.

I was just talking about symmetry of multimethods, say you had a generic 
function declaration such as:

generic_function< void (const bar&, const bar&) > gen_fun;

and you register a function like so:

gen_fun.def_method< const foo&, const baz& >(fun);  // where foo & baz are 
sub-types of bar

Now say you have 2 variables to use with this generic function that have 
there arguments the other way round:

baz b;
foo b;

gen_fun(b, f);

Now the hashed indices view will not find a matching function because the 
original function registered was with a combined hashed of the type 
identifiers of foo then baz but the combined hash of the type identifiers of 
baz then foo is not the same hash value which makes sense. It's not a 
problem with boost::multi_index_container it's just a slight flaw in my 
logic :)

It's not to much of a problem since an ordered view would still pick this up 
but it's not an (amortized) constant time operation it's logarithmic time.

>
> I'm quite proficient in Boost.MultiIndex so maybe I can be of some help.
> Unfortunately, I'm not understading the explanation of your current 
> probem,
> probably for lack of context. If you could provide me (either privately
> or through the list) with some more info and some code to have a look at,
> I can  try to help.
>

Thanks, i think i've managed to sort it now, it's wasn't an issue of using 
boost::multi_index_container per-say.

Now i've stumbed on another issue, originally the predicate function i was 
using for the keys of the ordered indices view was simply 
std::type_info::before but this causes some slight problems because 
std::type_info::before only gives a collating order of types, it does not 
tell you if one std::type_info instance is a sub/super-type of another only 
if one type proceeds another.

I can't use type traits any more since this is dealing with the runtime 
world. I can't use dynamic_cast to make runtime type queries because I have 
std::type_info instances not static types.

So does anybody know of a good method to determine if one std::type_info is 
a sub/super-type or another std::type_info.