[cfe-dev] Reflection

variadic.template variadic.template at googlemail.com
Wed Dec 15 15:22:01 PST 2010


> 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.
>

For sure, this is one possibility of implementing introspections. But I
don't like the thought of having the need of a database or another file
and another library for using the introspections in general. In my eyes,
it's neither smart nor fancy, and i prefer fancy solutions when possible.
I don't no yet, if my approach of generating introspection-informations
at compile time and inject them directly into the AST is sensible and the
right way to go, but for the moment, it seems right to me. Of course,
the introspections would be generated every time the compiler builds the
AST and that would be an overhead that could be avoided by your approach -
but i think this is nothing that the compiler should handle itself.

> 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.
>

For sure, this is a very interesting part of the introspections. As said,
I would have the ability to use this functionality without the need of
another library. At this part, maybe the JIT-ability of clang can be
useful, also.

> 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.
>

Yes, i also think that it would be a big help for C++ RAD.
For the moment, I am just at the very beginning to explore the clang-API
and how to use it. Maybe I'm going to use it for some code-transformations
where I have the need of deep code inspection. So I get some knowledge of
the clang-internals and some ideas of how introspections could be done with
it, and maybe (hopefully) i can spend some more time to realize some proof
of concepts later on.
When I have some useful results/experiences, i sure will post them here.




More information about the cfe-dev mailing list