[cfe-dev] Reflection

Stuart Carnie stuart.carnie at gmail.com
Tue Dec 14 10:04:44 PST 2010


David,

I believe you are correct, we are talking about introspection; I don't
believe anyone has mentioned extending or modifying existing types.  Example
use cases would be to inspect existing libraries and examine types of
interest, such as plugins, or those conforming to specific interfaces to be
used in a generic way.  At the risk of stating the obvious, a good example
would be to drop a library into a plugin folder of a paint application, and
be able to enumerate all the types derived from "ImageReader", enabling
my fictitious application to load several new image file types with zero
configuration.

Clang could benefit from this greatly too, by having an extensions path
where you could drop shared libraries, and no longer have to specify -load
-plugin, simply specifying switches to enable desired plugins.  There are
elegant ways to cache metadata extracted from a plugins folder so you don't
have to inspect the libraries on every invocation of the application.

Cheers,

Stu

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


On Tue, Dec 14, 2010 at 7:52 AM, David Chisnall <csdavec at swan.ac.uk> wrote:

> On 13 Dec 2010, at 18:37, Stuart Carnie wrote:
>
> > 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
> >
>
> It's worth noting that C++ already has some of this via RTTI, although not
> all of it is public.  The classes declared in <typeinfo> give you some
> information about an object via public interfaces (e.g. what its
> superclasses are and so on).  They also include a name field which contains
> an encoding of the field types.
>
> Unlike Objective-C, this encoding is defined by the ABI, rather than by the
> language, although you can use the typeid operator to get a type info object
> for a specific type and then use dynamic_cast<> to see which subclass of
> std::type_info it is.  The (BSD-licensed) libelf-tc library in the
> elftoolchain project has code for parsing these encodings for the old-GNU,
> new-GNU (Itanium), and ARM ABIs, so it wouldn't be too much effort to create
> something that gives you more useful introspection metadata.
>
> This information does not, as far as I am aware, give you type encodings
> for methods, so that would need to be added, which would modify the ABI
> somewhat (although not necessarily in an incompatible way).
>
> One question though: When you say reflection, do you actually mean
> reflection, or do you just mean introspection?  For example, true reflection
> would allow you to add methods to a C++ class, which would require modifying
> the vtable.  If you're only replacing methods, this is quite simple
> (although, again, ABI-dependent), but adding methods would be much harder.
>  Creating new types at run time would also be relatively difficult.  Simply
> extending C++ RTTI to provide useful introspection would be a lot easier.
>
> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101214/42cbd239/attachment.html>


More information about the cfe-dev mailing list