RTTI queries

[Jim Dehnert]

Following are the resolutions to Nathan's questions/suggestions from
last week's meeting.  I've also included them in the layout document.
I've also added a question at the end.

> Date: Thu, 06 Jan 2000 11:20:09 +0000
> From: Nathan Sidwell <nathan at acm.org>
> 
> 1) the declaration of __vmi_class_info uses a helper class of the
> following
>         struct __base_class_info {
>         type_info *type;
>         ptrdiff_t offset;
>         int vmi_flags;
>         }
> 1.1) I beleive `type' should be declared `__class_type_info const *type'
> (the description of __ptr_to_member_type_info has such a pointer and uses
> __class_type_info). The description of __si_class_type_info is vague on the
> base pointer's type, but that too should be `__class_type_info const *type'.

Yes.

> 1.2) From the description of __vmi_class_info it appears that the base
> class array uses the trailing array struct hack. This is ok, because
> it is always generated by the compiler. This is not documented.

Yes.

> 1.3) I cannot find a definition of what the `offset' member of
> __base_class_info is an offset for. For a virtual base it cannot be
> the offset from this base to the virtual base as that changes for different
> bases in a heirarchy. I presume it must be the offset in the vtable to the
> base offset. This is not documented.

Correct.  Now it is.

> 2) The ABI document specifies
> 
> void *__dynamic_cast (void *sub, __class_type_info *src,
>                 __class_type_info *dst, ptrdiff_t sr2dst_offset);
> 
> this is not const correct, I beleive it should be
> 
> void *__dynamic_cast (const void *sub, const __class_type_info *src,
>                 const __class_type_info *dst, ptrdiff_t sr2dst_offset);

Corrected.

> 3) __class_type_info contains a set of details flags. Whilst these look
> useful, I'm not sure that they are. When porting g++'s current dynamic_cast
> machinery (which as the document points out is semantically the same), these
> flags showed little use.

Discussion revealed some interest in this information for purposes
other than dynamic cast.  We decided not to think about removing them
until we get further along in the implementations.

> 3.1) flag 0x8 says `has privately inherited base'. Does this really mean
> private or does it actually mean non-public? both catch matching and dynamic
> cast distinguish public and non-public, not private and non-private.

Agreed that non-public is better.
 
> 3.2) More useful for dynamic cast, (and possibly catch matching) would be
> the following flags
> 	* Contains non-diamond shaped multiple base object
> 	* Is diamond shaped
> 	* has virtual base
> 	* has non-virtual base
> 	* has public base
> 	* has non-public base
> Note that the virtual/non-virtual and public/non-public are not mutually
> exclusive. Also note that I have not actually implemented anything with these
> flags, so I could be wrong.

Discussion was positive in principle.  We need a more precise
definition of "diamond shaped".  Can you provide that?

> 4) The name mangling scheme for type_info objects is not defined. Therefore
> I don't know how to name the type_info objects required in the runtime for
> the fundamental types (and their pointers). I see this is on today's agenda.

There's been some email discussion now, and we'll discuss it Thursday.
Daveed, will you send an update of your proposal based on the email?

I also notice that the document currently specifies namespace std:: for
many of the type_info classes.  Is this what we want, or should we use
our namespace abi::?  Also, can someone who knows please check that,
whichever it is, it is present everywhere it belongs (and not
elsewhere)?  Thanks.

> nathan
> 
> -- 
> Dr Nathan Sidwell :: sidwell at codesourcery.com
> nathan at acm.org  http://www.cs.bris.ac.uk/~nathan/
> 
-		Jim Dehnert  x3-4272

-		Jim Dehnert  x3-4272