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: BOOST_MIRROR_REG_CLASS_BEGIN(class,test,A) BOOST_MIRROR_REG_BASE_CLASSES_BEGIN BOOST_MIRROR_REG_BASE_CLASS(_,public,A_base) BOOST_MIRROR_REG_BASE_CLASSES_END BOOST_MIRROR_REG_CLASS_MEM_VARS_BEGIN BOOST_MIRROR_REG_CLASS_MEM_VAR(private,_,_,m_a) BOOST_MIRROR_REG_CLASS_MEM_VAR(_,_,_,m_b) BOOST_MIRROR_REG_CLASS_MEM_VAR(_,_,_,m_vec) BOOST_MIRROR_REG_CLASS_MEM_VARS_END BOOST_MIRROR_REG_CLASS_END 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) Stefan (1) 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.