Re: [boost] Re: [MPL] Type detection

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-23 10:18:49

On Thu, Oct 23, 2003 at 10:42:59PM +0800, Joel de Guzman wrote:
> Here, MPL style tag-dispatching allows unrelated iterator types
> to play along nicely.
> 
> There are 2 solutions I can think of:
> 
> 1) Have all iterators inherit from a base (BAD!)
> 2) Have an is_tuple_iterator<I> meta-function (better?)
> 
> I am of the opinion now that we need the is_tuple_iterator<I> metafunction
> to address this issue. If we did, it would solve (through enable_if) all-
> encompassing functions such as the operator* above. There are others: 
> next(i), prior(i) etc. 
> 
> I'd love to hear your thoughts. Perhaps there's another solution I am
> missing? Comments?

I plead ignorance (or lack of experience), but I am curious why #1 above
is bad, and why it is an alternative (rather than an accomplice) to #2?

The general strategy I tend to use for "enable_if-style
meta-predicates" is

 - write a meta-function 
      is_XXX<T>

 - have an empty base class which serves as the tag name
      struct XXX {};

 - have instances of XXX inherit the base class
      struct foo : public XXX { ... };

 - have the default implementation of the metafunction use
   is_base_and_derived to do the test

Is this bad?  Is there a better way?  I have been using this strategy
because

 - it works

 - it makes it easy to tag a new entity as an XXX (just inherit the tag)

 - the metafunction can be specialized, so you can specify that 
   3rd-party libraries which don't know they are XXXs become XXXs  
   (e.g. the typical "traits" advantage of extrinsic conformance)

but there may well be ways to get these advantages and more using other
design-of-implementation choices.  Comments?

-- 
-Brian McNamara (lorgon_at_[hidden])