[cfe-dev] Reflection

[Edward Diener]

On 12/14/2010 5:04 PM, variadic.template wrote:
> Introspecting C++/Objective-C-classes is what i am currently trying to do
> with clang. The idea of adding reflections to C/C++/ObjC is in mind for
> quite a long time. My main purpose is the serialization/deserialization
> of more-or-less complex objects into different formats, without having
> the need of using boost.serialization or something similar. For this
> purpose, traits would be sufficient and i think they should be included
> in an approach of realizing introspection. Of course, there should also
> be a dynamic runtime for the use of doing some scripting or other
> use-cases, which already have been mentioned.
> Also, the use of reflection-specific attributes should bear in mind.
>
> Thus, i wouldn't choose the approach of Russel, as you couldn't use
> the introspection-information neither in compile- nor in runtime,
> but only by the use of a third tool that reads the compiled bitcode -
> am i right?
> Nor i would chose a kind of preprocessing-phase, as purposed by
> Aurélien, as a preprocessing-phase sounds like to much overhead.
> My approach aims on generating the introspections immediately after
> clang has build the AST of a class/method/and so on. I currently don't
> know in what form the introspection should be generated - if it
> possible to generate an AST and inject it somewhere into clang itself,
> or if it has to be written in code temporary and then processed by
> clang, or something else - i have no idea what approach is possible
> and reasonable. The introspections should be accessible as classes in
> their own namespace - maybe configurable by the user by a macro or an
> attribute. You should be able to use them inside the same
> translationunit as the class/method/... itself got defined.
>
> These are my thoughts so far, still at the very beginning.
> It would be a great pleasure to see something going on in this area,
> and i think i could participate when those thoughts would reach in a
> project.

My suggestion is:

1) Take the C++ elements of a compilation and put them in a database. 
Whether the database must be a separate file or somehow connected 
directly to a C++ output is for you to study. Once the linker runs, take 
all the separate database information and put it together, again either 
in its own file or somehow within an executable, shared library, or 
static library output.

2) Write once a separate library which at run-time can introspect C++ 
type information using the database format you created based on the type 
of C++ information you have collected. This library should work with any 
information you have collected for any module.

3) Add a new hook into clang so that a keyword extension allows the 
programmer to introspect run-time information based on a type or an 
expression ( not easy at all, of course ). Something like 
'extended_typeinfo' which can be applied to any type or expression. 
Using something like this should enable a programmer to introspect the 
type at run-time.

A further difficulty of 3) is that introspecting any type should respect 
the access level of that type. What I mean is that if the code is within 
the type itself, then 'private','protected', and 'public' information 
for that type is accessible; if the code is within a derived type of 
that type then 'protected' and 'public' information is accessible; if 
the code is outside the type then only 'public' information is accessible.

Another goal is to allow the programmer to actually create an object of 
a particular type at run-time based on the name of the type as a C++ 
string. For that your separate library needs a function in order to do 
this and needs to create the object for the caller and return it in some 
way.

4) Interest others in your run-time reflection facilities and your clang 
extension to allow it to work, and try to interest the C++ standard 
committee in it also if it works well and finds excellent usages.

Yes, I have thought about this very much, but it is a huge undertaking 
and needs to be done in the right way. Someday with clang I may try 
myself as I believe that a C++ RAD environment can only be built with 
adequate run-time reflection. I wish you the best of luck in your pursuit.