[cfe-dev] Reflection

[Russell Harmon]

Ideally, you would use reflection as a dynamic API, and your use of
the API would be optimized into static reflection if possible.

My goal with this is to make it as language-agnostic as possible so as
to make it relatively easy to add generics to another language.
--
Russell Harmon



2010/12/13 Stuart Carnie <stuart.carnie at gmail.com>:
> 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 | 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
>>
>
>