Well, sometimes it's needed at compile-time. Though, I don't know how useful
it is. Can you give an example?
Some other questions. How to map member pointers to names? How to find a
member?
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
David Abrahams wrote:
> Alexander Nasonov <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> A problem with this is that the introspection information is only
>>> available at runtime. A more-flexible system would use GCC-XML output
>>> to generate something like:
>>>
>>> template <>
>>> struct class_<Driver>
>>> {
>>> typedef mpl::vector<Person> bases;
>>>
>>> typedef mpl::vector<
>>> member<int Driver::*, &Driver::licence_id>
>>> , member<Date Driver::*, &Driver::licence_issue_date>
>>> , member<void (Driver::*)(), &Driver::accelerate>
>>> > members;
>>>
>>> ...
>>> };
>>>
>>> So all the introspection information could be available at
>>> compile-time.
>>
>> Sometimes it's fine to have an introspection only at runtime.
>
> And sometimes it's not.
>
>> I just want to avoid duplications of class descriptions by multiple
>> libraries.
>
> Which is exactly why, if you're going to write an introspection
> framework, it should make information available in a form that works
> for libraries which may need it at compile-time.
>
>> For example, Python and luabind could share common
>> introspection information.
>
> Sure, great idea.
>
>> This is why I'm using visitors. Every intronspection elelemnt has
>> correspondent node that can be visited. The challenge is to build a
>> complete set of nodes with a complete set of operations.
>
> Sure, great idea. Why not a compile-time visitor, though?
>
> mpl::for_each anyone?
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
