Hi Jean-Louis, I've merged several of Your posts so I can reply in one message, lazy me, sorry ;-P
I'm taking a look at it. It looks like my work picks up where yours stops. It is certainly worth making my library capable of perusing mirror's compile-time info. Or maybe my work should be merged in mirror...
I was thinking about writing a separate run-time library that would use Mirror as the source of the basic compile-time info. My idea is to define an abstract interface similar to the mirror's but polymorphic.
I'll try to upload my stuff to the sandbox before leaving for vacation this thursday.
I would be glad to work together with somebody on this, but I ain't going to make any promises ;), because right now I'm in a kind of deadline situation so don't have much free time to work on Mirror. Actually we've talked with Joel Falcou that we could work together, but ... since then I hardly found some time to work on the mirror docs. Hope it will be better at the end of this / the beginning of the next year. On Tue, Nov 4, 2008 at 12:17 AM, Jean-Louis Leroy <jl@yorel.be> wrote:
Jeremy Pack wrote:
Jean-Louis, Boost.Reflection handles multiple and virtual inheritance fine.
Does the version from http://boost-extension.blogspot.com/2008/07/latest-release-downloadable.html contain support for inheritance already?
My primary interest is not in reflection per se, for me it's just a tool upon which one can build generic object-processing tools like dumping objects to text descriptions or XML or implementing object-relational mapping.
Support for serialization and object-relational mapping is also one of my motivations for writing a compile time reflection library. Actually it is sad that the C++'s "reflection" abilities are limited to ::std::type_info, the typeof operator and bunch of other stuff, because compilers have a lot of useful information that the programmers could use, but cannot access in any portable and standardized way. The potential authors of a proposal of a good compile-time reflection facility for C++ will be my heroes. :) Sure, there are tools like gcc2xml, openC++ and some others but most of them are platform/compiler specific and using them in big projects tends to be difficult. But I was thinking (suprisingly enough) about gcc2xml being used as an optional support for automated registering of things into mirror, on those platforms where it is available.
Once we have reflection, we need a way to deal with fields in a generic manner, whatever their type: int, vector<int>, vector< vector<int> > etc. One solution is to reflect the structure of the field's type as well: make the field class contain a pointer to a polymorphic type object, from which one derives int_type, a vector_type - which contains in turn a pointer to the element's type - etc. Pattern freaks will call it a composite ;-)
The next step is multimethods. Once we have them we can write code like this:
// using BS's proposed syntax in D&E void process_type(virtual type&, virtual processor&, void*);
void process(instance i, processor& p) for each field (i) process_type(*field->type, p, field->address(i))
class text_dumper : public processor { ... };
void process_type(virtual int_type& t, virtual text_processor& p, char* pv) { p << *reinterpret_cast<int*>(pv); }
void process_type(virtual vector_type& t, virtual text_processor& p, char* pv) { p.indent(); char *iter = t.begin(pv), last = t.end(pv); while (iter != last) { process_type(t.element_type, p, iter); t.forward(iter); } p.outdent(); }
What do you think of the idea?
Mirror provides class and class instance *traversals*, which "guide" custom user-defined generic visitors through the structure of a class and optionally also allow to work with instances of that class in a generic way. Generaly the traversal calls the visitor's member functions like enter_type, leave_type, enter_base_classes, leave_base_classes, enter_attributes, leave_attributes, etc. depending on the reflected class' declaration, with appropriate arguments. The traversals can also provide the visitors with x-path-like ;) meta-paths that can give insight about the context in which the visited base_class, attribute, ... etc is visited. Another way how to work with member attributes, base classes, etc. is to use the algorithms like for_each or the iterators provided by mirror. This features are unfortunately still undocumented, there are however several examples showing how to use them included in Mirror.
Jean-Louis
Best ________________ ::matus_chochlik