Re: [boost] [OT][RFC] standardized compile-time reflection

Subject: Re: [boost] [OT][RFC] standardized compile-time reflection
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2012-04-25 09:38:24

On Wed, Apr 25, 2012 at 12:15 PM, Hite, Christopher
<Christopher.Hite_at_[hidden]> wrote:
> I'm going to put in my own 2 cents. Â Right now I'm using metaprogramming to generate fusion::maps as structures. Â Perhaps one day it'd be better to use something like mirror to go the other way or combine a meta-programatic protocol description with a user defined structure with a subset of the fields he wants. Â It'd be way easier for a user to deal with a regular structure than a generated fusion::map.
>
> 1) Someone mentioned it being problematic to iterate of members of a namespace. Â I think it souldn't be done since additional compliation scopes can add more to a namespace. Â Namespaces are open ended. Â A complete structure should be no problem though.

It is true that the list of members of a namespace can be different
in two or more translation units based on what headers are included
for example. But there are many use-cases where the inspection
and traversal of members of a namespace is very useful.

I work for example on (a unfortunately closed-source) application that
is part of a kind-of-ORM-system which traverses the classes in
a namespace and generates SQL DDL commands to create
database objects (types, tables, ...) based on the meta-data.

>
> 2) AFAICT mirror doesn't work for templates types or template members.

mirror or Mirror :) ?
Mirror is not a perfect library. A lot of support from the compiler is necessary
to get reflection right.If you are talking about the 'mirror'
function/meta-function
then, yes that would have its limits too (see 3))

>
> 3) I'm more for a meta-function syntax than an operator. Â To me mirror<T> seems like a natural extension of type traits.

In an ideal world I would prefer the operator, because it would be more
"powerful", consistent, "nice", etc.,  but I see why it may be a bad idea
in the current reality. Getting the meta-data for the global scope
namespace and arbitrary types should be enough.

>
> 4) Should mirror< mirror< T > > Â work?

There is a MetaMetaObject concept in Mirror, but I've been
kind of struggling in its design. It is useful in some cases though.

>
> 5) Should conversion ever work the opposite way? Â Should I be able to meta-programatically generate types from your representation:
> typedef unmirror< addField< mirror<T>, "member", int> > NewT;
>
> Obviously that would require a ton of compiler magic, but might be something to think about.  Is your representation easy to manipulate/generate?  How cubersome would addField<> be?
>

I've also thought about this, IMO such feature would find a lot
of use-cases and open "new horizons" :) for compile-time
meta-programming, but designing and implementing it might
be quite difficult.

I'm not sure what the compiler vendors would say to that.
Also I don't want the proposal to be too bloated. Too much
complexity is IMHO one of the reasons why C++0x concepts
were rejected.

Best,

Matus