On Wed, Apr 25, 2012 at 12:15 PM, Hite, Christopher <Christopher.Hite@partner.commerzbank.com> 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