Re: [boost] Library Proposal: Reflection for C++

From: Edward Diener (eddielee_at_[hidden])
Date: 2006-02-05 18:36:23

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.