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?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
