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

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-10-23 11:32:58

Brian McNamara <lorgon_at_[hidden]> wrote:
> 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?

Because it is intrusive. There are cases where we want to adapt an already
existing iterator. For instance, I can't ask the MPL author to please subclass
from this base class so I can use his iterator.

If external extensibility is not a requirement, definitely, #1 is the best choice.

> 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

If I have control over all classes, I'd defninitely choose that approach.
There are cases where you don't. For example, we can't force users
to subclass from a base functor class, it has to be a free F type.
The same is true with iterators. I can't imagine a scenario where a
library such as STL would require all iterators to subclass from a base 
iterator class.

>  - it works

Yes, of course. Albeit forcing intrusiveness.

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

I use that technique often, if possible.

>  - 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)

Right. 

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

Well, I've given my comments. As I said, if I have control over all the
participating classes, I'd definitely choose that path. In this case, as
with STL iterators, functors,  etc. we can't force the user to subclass 
from something.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net