From: George van den Driessche (grebe_at_[hidden])
Date: 2004-11-10 10:14:56
> Message: 7
> Date: Tue, 9 Nov 2004 13:16:05 -0500
> From: Caleb Epstein <caleb.epstein_at_[hidden]>
> Subject: Re: [boost] Re: GUI Library Proposal for a Proposal
> To: boost_at_[hidden]
> Message-ID: <989aceac0411091016316d09bb_at_[hidden]>
> Content-Type: text/plain; charset=3DUS-ASCII
> On Tue, 9 Nov 2004 17:37:15 -0000, George van den Driessche
> <grebe_at_[hidden]> wrote:
> > > Date: Tue, 9 Nov 2004 09:38:35 -0500
> > > From: Caleb Epstein <caleb.epstein_at_[hidden]>
> > > I've been toying with using the properties library Reece Dunn recentl=
> > > submitted (in the boost-sandbox CVS) for this purpose. I've got
> > > something very sketchy, but it relies on a visitor pattern to "pass"
> > > type information to client code in a manner similar to Boost.Variant.
> > >
> > > I'd prefer a way of storing the type information for each reflectable
> > > class statically, and in a generic way, e.g. something like
> > > std::map<std::string, property>. This would enable the reflection
> > > code could be decoupled from the reflected classes entirely and just
> > > operate on this property meta-data. It would also allow client code
> > > to lookup individual properties (e.g. by name) instead of having to
> > > visit all of them.
> > >
> > > I'm stumped by how to store this information in any sort of container
> > > though, since the properties are of different types. Any thoughts, o=
> > > is this madness?
> > The properties are of different types, but the type information for
> > properties will always be of the same type :) So you can generate a pro=
> > set for your class, that includes the dictionary that maps names to
> > property_type_info structures. Each property_type_info would be
> > automatically generated from the static type of the property.
> You lost me here. The property types each inherit from property_info,
> but it is similarly templated on the type of object begin
> stored/referenced/aliased. Are you suggesting another non-template
> base class which all properties would inherit from?
Spot on. Just as a property_set corresponds to a C++ type, the
property_type_info entries in the property_set each correspond to a
pointer-to-member (or a pair of pointer-to-member-function if you want to
wrap your property with get/set methods). Just as you generate a unique
property set for each reflected type, you generate a unique property_info
for each of its properties. But since each property_info has a common base
class, you can stick them all in the same property set.
Take a peek into the Boost.Python stuff. It follows a similar pattern, I
> What might this
> look like?
I find myself unable to write an overview of it and not almost all of it. So
I'll have to write the whole thing this evening when I have time :)
> What mechanism would you use to keep track of the type
Type information of what? You can pass around a fat pointer class which is
basically a pair< void*, property_set* > when you need to maintain knowledge
of the type of a pointer.
I'll try to get it all written up into an understandable form this evening.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk