Re: Inheritance graph

Daniel Wallin <[email protected]> writes:

> At 09:52 2003-08-14, David Abrahams wrote:
>
>>I think I understand where you're going with this... but I don't
>>think this overloading is much help because AFAICT it's just a way to
>>avoid ODR problems... and there's no way a single extension is going
>>to use two different TYPE_INFO systems, is there?
>
> No, a single extension has to use only one type_info system. But the point
> was to allow configuration of the type query functions. 

I guess you mean so that different *implementations* of type info
extraction can be plugged in to handle the different info types?

> How could this be done otherwise? I can only think of macros.

It could be done with specialization:

   template <>
   struct type_id_traits<python::type_info>
   {
      template <class T>
      static python::type_info static_type_id(T*) ...; 

      template <class T>
      static python::type_info dynamic_type_id(T*) ...; 
   };

   template<class T>
   type_info static_type_id(T* x)
   { 
     return type_id_traits<type_info>::static_type_id(x);
   }

   etc.

I think that's a marginally superior approach.

>> > I think we need to discuss the configuration solutions more.
>>
>>Yeah.  Do people really need to pick arbitrary type_info types?  Can't
>>we just package a few which are macro-selectable?  I don't like the
>>idea of storing a type in a macro value, but I guess if it's just for
>>the purposes of setting up a typedef to be used thereafter, it's fine.
>
> I think it's a nice goal to be able to use luabind/bpl with any existing
> type_info system. 

OK.

> For example, it's very common to have virtual query member functions
> instead of using RTTI.

But Boost.Python requires the ability to get type information when
there is no actual object.  In fact, that's *mostly* what it
requires -- there are many more uses of type_id<T>() than typeid(x).

> What specifically is your issue with storing a type in a macro? 

I dunno.  "Feels dangerous".

> And how would selecting a package with a macro be any better?

Less variability; easier to detect user errors.  This is all just
vague FUD; probably not justifiable.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01