Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at