[boost] [e-mail]

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-11-15 01:14:58

Vladimir Prus wrote:

>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).

hmmm - 

extended_type_info is the same type of information that typeid returns plus some extra.
We use it as surrogate for typeinfo because we want to store some extra
information and we want to be able to support system that don't have rtti
and std::typeinfo.  For each type system there is an extended_type_info class
(one for rtti, etc).  

pointers to all extended_type_info records are kept in a set of polymorphic
pointers. Two extended typeinfor records are considered equal if and only
if they uses the same extended_type_info class as well as have the same key.

so comparison first checks that the two candidates are use the same
extended_type_info class and only then that they have the same key.
That is, two comparisons are required to deterimne equality of keys.

>The last remark. I'd really appreciate much more comments in the code. 

I'll try to do better.  If you want to submit of list of specific things, I'll be
glad to add comments to that part of 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.

I'm not sure how to improve this.  The code is large and pretty complex.  Dividing
into smaller modules and better factoring have helped.  Of course the 
fact that its clear to me makes it harder for me to explain it better.  Also
makeing it hard to explain is that I had to use almost every feature of C++
to get it work - mpl, runtime virtual functions, static virtual functions (CRTP),
spirit each of which consumes a lot of effort to understand.

>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. 

The Manual does have a section on Type Information Implemenation which
touches upon this question.  I suppose things would be helped by including
a section on "Adding a new type implentation".   I do wonder if anyone
will actually use this.  Included this facility as it was requested in the 
original review.

Robert Ramey