rtti

[Jim Dehnert]

> Date: Mon, 12 Jun 2000 22:27:56 +0100
> From: Nathan Sidwell <nathan at codesourcery.com>
> 
> Here's G++'s cxxabi.h and related files for comments, and my findings
> about action item 37. For those unfamiliar with gcc's runtime layout
> here's what the files contain
> 
> typeinfo	class type_info declaration
> cxxabi.h	the abi's support type_info classes and prototypes
> vec.cc		the abi's vector new and delete helpers
> tinfo.h		runtime header for tinfo.cc & tinfo2.cc
> tinfo.cc	dynamic cast and catch matching routines
> tinfo2.cc	abi's non-class type_info definitions
> 
> the latter 3 files contain a big #if for gcc's old and new abis. for the
> new abi __GXX_ABI_VERSION will be 100. Also, gcc doesn't provide <cstddef>
> (but it's part of the library), so std::size_t, std::ptrdiff_t aren't
> available in the header files, hence the use of __SIZE_TYPE__ and
> __PTRDIFF_TYPE__ in header files.

I've added these files to the web site, referenced from the summary
page.  We may want to clean out the non-ABI parts at some point and
reference them from the draft ABI (as non-normative examples).

> 1) The class definitions in cxxabi.h have inconsistent names for the data
> members. In some cases each field is prefixed with the shortened class
> name (for instance __vmi_class_type_info::vmi_offset_flags), in other
> cases the abi doc doesn't specify a name, and there is no prefix (eg
> __pbase_type_info:::quals). My preference is for non-prefixed names,
> as that is a more usual in C++ (after all, we've had structure scope
> for a long time). We should use a consistent naming scheme, and I'd
> prefer it to be the non-prefixed form.

I've put this on the agenda for tomorrow.  If we have concensus to do
this, we'll need someone to go through carefully and identify all the
changes.  Or maybe we can do it at the meeting...

> 2) As to the usefulness of __vmi_class_type_info::non_public_base_mask
> and __vmi_class_type_info::public_base_mask. It transpired that neither
> were useful. there were two places where public_base_mask might be used,
> but I suspect that to be premature optimization. non_public_base_mask
> turned out to not be useful. In all cases of considering a non-public
> base, one already knew the base was non-public, and the
> non_diamond_repeat_mask and diamond_shaped_mask were useful. Therefore,
> in resolution of item 37 I propose removing both non_public_base_mask
> and public_base_mask from the vmi_flags.

Also on the agenda for tomorrow.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272