Boost logo

Boost :

Subject: Re: [boost] [intro] Preview: Introspection library
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-06-29 04:24:50

>>>>> template<class Mapping>
>>>>> friend void introspect(Mapping mapping,type<A>){
>>>>> mapping
>>>>> (base_class<A_base>() )
>>>>> (member<A,int ,&A::m_a>() )
>>>>> (member<A,float ,&A::m_b>() )
>>>>> (member<A,std::vector<int>,&A::m_vec>())
>>>>> ();
>>>>> }
> I would be interested in some examples if you were kind enough to
> provide them.

for algorithms? serialization. see my initial mail for a list.
for concept implementation? I'll try my best, using your documentation
only and the same class as above:


inherent in a reflection library is that the "registering" concept
defined by it will be imposed on the library end user, i.e. if I write
a library that needs reflection on types and I use Mirror for that, I
require the user of my library to implement the mirror concept for
each type.
besides my dislike for the use of macros, the user should not have to
provide any information that isn't required by the component requiring
reflection on (parts of!) that type.
the component using reflection might also require additional
information provided by the user, e.g. in the case of a lot of Intro
algorithms, whether a pointer refers to shared memory or not:

      (member<A,B *,&A::ptr_to_B,shared_pointer>() ) //(1)

or tag names for XML serialization, or ...

I'm not saying that I have a better way to register classes/members in
Mirror, I'm not even sure there is a better way.
just trying to explain why requiring the user of the library that uses
Intro to register all his types in the way shown above wasn't an option.
I don't like the introspect() concept either and would have rather
used Serializable, but it is the best I could come up with, and
Serializable results in very inefficient algorithms especially when
using more than one instance at a time (e.g. copying an object, or
comparing 2 objects)


shared_pointer is the default semantics for type "B *", so it doesn't
have to be specified.
typedefed to
semantics<mpl::set<unique,sealed>,semantics<mpl::set<shared,polymorphic> > >,
i.e. the member ptr_to_B itself is unique, but the object it is
pointing to might be pointed to by other pointers (shared), and might
not have type B but a derived type.

Boost list run by bdawes at, gregod at, cpdaniel at, john at