[cfe-dev] Reflection

[Cédric Venet]

Hi,

Good point, i didn't think of this. However, when not loading the shared 
library, do you need the full reflection information? or could some 
metadata (custom attributes) and perhaps a list of class be enough (in 
fact this is already available from the symbole list)? The main 
drawbacks I can see for your approach is that:
* executable format dependent data loader
* you must generate the data yourself (what about member offset, 
function adress and interaction with relocation,...)
* some functions refered by your data could be pruned by the linker 
because unused or inlined,, but still have reflection reference

However, i do not know what your use case is. Mine would be things like 
script binding, generic property exploreur, (de)serialisation, data 
dumping/printing for debug... In all these case the dll would be loaded 
anyways. But since I do not have times to work on it, do wathever you 
want. I was just thinking your way needed more work.

regards,
Cédric

On 13/12/2010 21:58, Stuart Carnie wrote:
> Cédric,
>
> Your suggestion is quite reasonable, however in your scenario you must 
> load the shared object / library into memory and execute code in order 
> to enumerate the metadata.  You will incur all the performance 
> penalties for loading shared libraries for executable purposes, such 
> as rebasing, etc.  A particularly useful scenario for reflection is to 
> scan a directory of libraries and determine available features or 
> plugins, that would be quite costly if they all had to be dynamically 
> loaded.  It would be fairly easy to abstract the reading of the 
> metadata from a specific data section.
>
> My scenario still does not require changes to LLVM or the C++ 
> language, only changes to Clang to generate the metadata.
>
> Good discussion, either way, as it would make it easy to generate 
> scriptable C++ libraries in a non-invasive way.
>
> Cheers,
>
> Stu
>
> *Stuart Carnie, CTO*
> *manomio <http://manomio.com/> | in retro we trust!*
>
>
> On Mon, Dec 13, 2010 at 12:12 PM, Cédric Venet 
> <cedric.venet at laposte.net <mailto:cedric.venet at laposte.net>> wrote:
>
>
>
>     Le 13/12/2010 19:37, Stuart Carnie a écrit :
>     > 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.
>
>     Static reflection is useful, but I agree it is a (completly) different
>     problem. However, your proposal still seems quite complex and
>     invasive.
>     Why not juste store the reflection data in C++ structures and expose
>     them by the mean of global const static object?
>
>     something like:
>
>     **** input
>     struct Foo
>     {
>       void f();
>       int a;
>     };
>
>     **** generated by clang
>     // Contain functions for decoding the reflexion information
>     struct reflection::class_data_base  {
>       void EnumMembers(Fct callback);
>       int GetValue(const char* name);
>       void Call(const char* name);
>       //...
>     };
>     // for name mangling
>     struct reflection::class_data<Foo>:reflection::class_data_base {
>       static const int num_members=2;
>       // obviously pseudo code :)
>       static const datatable=[ "f", &f, "a", &a ... ];
>     };
>
>
>     This would allow to not modify llvm and C++ code could be generated by
>     clang for other compiler. Clang does not need to generate the
>     reflexion
>     code, it could create an ast or codegen it directly.
>
>     This would also make it portable, no need to access metadata in an
>     executable...
>
>     Hope this makes sense.
>     Anyways just my two cents. Good luck on your project, it is really
>     interesting and useful (especially with the rise of fast scripting
>     language).
>
>     regards,
>     Cédric
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at cs.uiuc.edu <mailto: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/20101214/880b52da/attachment.html>