Re: Re: Inheritance graph

At 14:15 2003-08-14, David Abrahams wrote:
>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?

Right.

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

Ok, this is pretty much the same thing so if you think it's
better, I'm convinced. :)

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

Right, so does luabind. This is what static_type_id() would do. You could
have static type identifiers as well as virtual query functions.

template<class T>
struct id_traits;

template<>
struct id_traits<my_type>
{
    BOOST_STATIC_CONSTANT(std::size_t, id = 1);
};

struct my_type : base_type
{
   virtual std::size_t type() const { return id_traits<my_type>::id; }
};

struct my_type_info
{
    my_type_info(std::size_t);
    ...
    std::size_t id;
};

#define BOOST_LANGBINDING_TYPE_INFO my_type_info

template<>
struct type_id_traits<my_type_info>
{
    template<class T>
    static my_type_info static_type_id(T* = 0)
    { return my_type_info(id_traits<T>::id); }

    template<class T>
    static my_type_info dynamic_type_id(T* p)
    { return my_type_info(p->type()); }
};

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

Ok.

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