[cfe-dev] Reflection

variadic.template variadic.template at googlemail.com
Tue Dec 14 14:04:49 PST 2010


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.

> This is actually very interesting, and I was also looking to achieve
> something similar. However, I chose to do the things differently.
>
> As C++ is statically typed, why bother with dynamic reflection, while you
> can achieve a more efficient, cleaner static reflection?
> I rather thought of kind of preprocess phase that would add traits on
> classes containing their members, methods, etc... The reflection would be
> implemented by using these generated traits. We then could add a post
> reflection processed target that would simply prints the traits, thus
> allowing to have a standard C++ code buildable with any compiler.
>
> struct Foo
> {
>   void f();
>   int a;
> };
>
> The generated traits may look like (very roughly):
>
> reflect_trait<Foo>::attribute::count
> reflect_trait<Foo>::attribute<1>::type
> reflect_trait<Foo>::attribute<1>::name
> reflect_trait<Foo>::method<1>::type
> reflect_trait<Foo>::method<1>::signature
> reflect_trait<Foo>::method<1>::name
> reflect_trait<Foo>::method<1>::param::count
> etc..
>
> Just my 2 cents
>
> On Mon, Dec 13, 2010 at 2:49 PM, Russell Harmon <russ at eatnumber1.com>  
> wrote:
>
>> I'm looking to possibly add support for reflection to clang & llvm.
>> I'm thinking it would work something like the following:
>>
>> - clang inserts reflection information into the compiled bitcode
>>  - does debugging symbols provide enough information already?
>>  - should this be a new symbol table, or an extension of the debugging
>> symbols?
>> - I write a c library which using the symbols from the compiled
>> binary, allows you to do reflection
>>  - A typeof() or similar builtin will be necessary
>> - I'll need to eventually modify llvm's optimizer somehow so that it
>> doesn't break the reflection information
>>
>> Thoughts?
>> This is going to be my introduction to the llvm & clang code base, so
>> any advice on where to start?
>>
>> -Russell Harmon
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
>





More information about the cfe-dev mailing list