[cfe-dev] Reflection

[Stuart Carnie]

Static reflection seems to be very limited.  Reflection is a powerful
mechanism for being able to analyse a 3rd party executable or dynamic
library and interact with it at runtime, dynamically invoking APIs.
 Objective C already has this, so you should be able to to leverage the same
concepts for a C++ version.  You already have a great example in Clang;
Objective-C provides all it's reflection through the runtime APIs, and
therefore a C++ extension could do the same thing.  No built-in's,
alterations to LLVM or changes to the C++ language.

The reflection information is merely metadata generated at compile time to
describe the symbols in a specific module.  A lot of the work is around the
runtime.

I imagine some of the things you would need are:

   - A runtime, similar to Objective-C's, which needs some of the following
   capabilities
      - collection of metadata classes which describe methods, types, etc
      - APIs to read over data sections to extract metadata and generate
      aforementioned classes
      - Public APIs to query for this metadata, create instances of classes
      via name, etc
   - Changes to compiler
      - Generation of metadata into special data section
      - Generation of entry points / APIs to compiled libraries,
      executables to allow you to do things like create instances of classes
      / types by name, etc

Cheers,

Stu

*Stuart Carnie, CTO*
*manomio <http://manomio.com/> | in retro we trust!*


2010/12/13 Aurélien Vallée <vallee.aurelien at gmail.com>

> 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
>>
>
>
>
> --
> Aurélien Vallée
> +33 6 47 41 70 37
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101213/dafd207e/attachment.html>