Re: Re: Inheritance graph

At 09:52 2003-08-14, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > At 01:37 2003-08-14, David Abrahams wrote:
> >>Daniel Wallin <[email protected]> writes:
> >>
> >> > FYI, I've messed around with the code in inheritance.cpp /
> >> > inheritance.hpp and made it into a real singleton. In this process I
> >> > also investigated type importing, and to me it seems complicated to
> >> > try to share any data at all between modules.
> >>
> >>Yes, it's at least complicated.  However, given the size of the cache
> >>it does seem expensive not to share when multiple modules interact.
> >>
> >> > Also, I've looked into library configuration. I ended up with one macro;
> >> > BOOST_LANGBINDING_TYPE_INFO, which is the type used for type
> >> > identification.
> >>
> >>Is there some reason we'd have to use a MACRO instead of a typedef??
> >
> > Well, the point was to allow for easier configuration. With a macro you can
> > generally just pass it to the compiler as a command line option, rather 
> than
> > editing some library configuration header.
> >
> >> > I also did something like this (python::type_info used for
> >> > illustrative purposes):
> >> >
> >> >    typedef BOOST_LANDBINDING_TYPE_INFO type_info;
> >> >
> >> >    template<class T>
> >> >    type_info static_type_id(T*, type<python::type_info>)
> >>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^
> >>What is this argument for??
> >
> > It's just a thought, configuration by overloading. Define the
> > type_info type with BOOST_LANGBINDING_TYPE_INFO and overload the
> > type query functions for that type.
>
>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. How could this be
done otherwise? I can only think of macros.

> > 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. For example, it's very common to have virtual query
member functions instead of using RTTI.

What specifically is your issue with storing a type in a macro? And how
would selecting a package with a macro be any better?

---
Daniel Wallin



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