Thursday agenda

[Jim Dehnert]

For your preparation purposes, note that the agenda will include:


  2) G-4:  Thread-safe data initialization.  See 3.3.2.  Christophe
     had some ideas for optimization here.  I've updated 3.3.2 a bit,
     but the discussion of potential changes for Christophe's
     concerns is in the open issues page for issue G-4.  Christophe,
     can you take a look at it?

and this subject:

> From: Martin von Loewis <loewis at informatik.hu-berlin.de>
> 
> I have concerns that the current RTTI spec does not allow
> implementations to interoperate. The core of the issue is whether
> there should be a vtable pointer in class type_info.
> 
> The current (modified) draft specifies no virtual functions. I believe
> it is not possible to implement this specification: Inside
> __dynamic_cast, you need to know whether the __class_type_info is a
> __si_class_type_info or a __vmi_class_type_info. Likewise, in
> exception handling, you need to know whether the types are
> __pointer_type_info or not, and whether the __pointee field is a
> __class_type_info.
> 
> In extension of what is specified, the current GCC adds a number of
> virtual functions to the derived type_info classes, such as
> __is_function_p, __do_catch, __pointer_catch, and so on. However,
> unless specified in the ABI, other compilers won't fill the vtable
> pointers of the derived classes to point to gcc's vtables. With the
> current spec, the other compilers won't even allocate a vtable field.
> 
> Furthermore, there is currently no guarantee that there is only a
> single vtable per type_info class if objects from multiple compilers
> are mixed. For example, in gcc, these vtables live in libgcc.a, which
> is incorporated into any shared library. If a different compiler uses
> the same strategy, you'd end up with two definitions for, say, the
> __vmi_class_type_info vtable - and they would have a different layout.
> 
> I see two solutions:
> a) specify exactly which virtual functions must be provided to
>    implement the routines mandated by the ABI (i.e. dynamic cast
>    and EH matching)
> b) provide some basic identification mechanism on top of which
>    these ABI routines can be implemented. 
> 
> I favour alternative b), and propose the following definitions
> 
>   namespace std{
>      class type_info {
>       private:
>         const char *__type_name;
>         virtual ~type_info(); /* to give it a vtable */
>      };
>   }
> 
>    namespace abi{
>      enum ti_kind{ /* in the order of exposition in 2.9.5.3 */
>        /* type_info is abstract */
>        fundamental_type_kind = 0,
>        array_type_kind = 1,
>        function_type_kind = 2, 
>        enum_type_kind = 3,
>        /* __class_type_info is abstract */
>        si_class_type_kind = 4,
>        vmi_class_type_kind = 5,
>        /* __pbase_type_info is abstract */
>        pointer_type_kind = 6,
>        pointer_to_member_type_kind = 7,
>      }
> 
>      class type_info: std::type_info {
>        virtual ti_kind kind();
>      };
>    }
> 
> All other type info classes inherit from abi::type_info. The leaf
> types override the kind() function, so the implementation must provide
> a suitable vtable for them.
> 
> Disclaimer: I haven't actually verified that __dynamic_cast can be
> implement on top of these informations. If required, I'll try to
> produce a sample implementation in gcc.
> 
> Regards,
> Martin
> 
-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272