Sebastian Redl wrote:
Edward Diener wrote:
Can you give an example of the compile-time use of reflection for templates and how this would be done ? Or have I completely misunderstood what you and Sebastian Redl are discussing ?
Although this came up in a different branch of discussion, the topic of David and my discussion was about the hardships of implementing a solution that could, at run-time, instantiate a template and load the newly generated code into the application.
Clearly one can normally, from a template definition, instantiate a template at run-time in C++ now. How is this different from what you are suggesting above ?
But for an example of compile-time reflection, I posted something a few days ago, in the thread about a policy selector using a mpl vector of policy classes. There, I used the mpl utility macro BOOST_HAS_NAMED_TYPEDEF (I think is the name of the macro.) This is one very limited example of compile-time reflection. Real language support would allow for far more interesting things here. My example implemented this compile-time pseudo-code:
metafunction type policy_type(type policy) { if(policy.has_typedef("policy_type")) { return policy.policy_type; } else { return not_a_policy; } }
OK, I understand this. In a run-time reflection mechanism, one would be able to find about type 'policy' and any nested types, member functions, or data members it contains but admittedly whether it had a nested typedef would be lost to a system at run-time.
Overloads (= specializations) could be provided for types that had a policy_type but no nested typedef policy_type. The has_typedef would basically be a part of compile-time reflection.
However, reflection would be far more powerful. Instead of just testing for the existence, you could for example enumerate all typedefs.
Agreed. There are situations where a run-time reflection mechanism would not give you what you need to know for template programming. As I understand it the solutions to this problem would be either a compile-time reflection mechanism as part of C++ or a compiler implementation, or a step which manipulates C++ source code based on compile-time reflection data before the compiler processes it. For the purposes of Boost, because it can not change every compiler on the market, and C++ has no built-in compile-time reflection, the second solution would appear ro be the only one.