[boost] Re: Review Request: FC++

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-09 21:01:05

Mat Marcus <mat-boost_at_[hidden]> writes:

> --On Thursday, October 09, 2003 2:51 PM -0400 Brian McNamara
>   <lorgon_at_[hidden]> wrote:
>
>> On Fri, Oct 10, 2003 at 01:54:04AM +0800, Joel de Guzman wrote:
>>> David Abrahams <dave_at_[hidden]> wrote:
>>> > Douglas Gregor <gregod_at_[hidden]> writes:
>>> >> We've discussed this before, although I can't find a reference
>>> >> to it because I believe it was an e-mail conversation.  The
>>> >> reason we did not name the "result" member class template
>>> >> "apply" is that we envisioned function "object types that were
>>> >> both metafunction classes and function objects, "and therefore
>>> >> would have both "apply" (in the MPL sense) and "result" (in the
>>> >> result_of sense) member class templates.  For instance:
>>
>> Based on this discussion, perhaps the best choice for FC++ is...
>>
>> Rather than having each functoid type being a metafunction (e.g.
>> "map_type" is a metafunction to compute the result type of the "map"
>> functoid based on its argument types), instead have either a nested
>> type or an external traits thingy "as_metafunction".
>>
>> Yeah; this generalizes then from FC++ to everything that supports the
>> result_of stuff.  I'm imagining:
>>
>>    // For every type F, where F supports result_of
>>    metafunction_result_type_computer<F>
>>
>> is the corresponding metafunction which computes the result type
>> based on the argument types.  I think this is the most general
>> abstraction.
>
> Yes! At the risk of repating myself from the recent "Beyond Objects"
> thread: Down with members, nested types and trais, in public
> interfaces :-)
> It's that darned OO mentality that's so hard to shake loose on the way
> to generic design. Having the return type calculator as a free
> metafunction seems like just the ticket.
>
> [snip]
>> The problem, of course, is that it is not terse.
> [snip]
>
>>
>> Hmm.  Is there some point in the design space here that optimizes
>> all of the various considerations?
>>
>
> Hmm. Good question.

The usual trick is the same one used by iterator_traits: the default
implementation (unspecialized version) dispatches to some member, for
convenience.  This, or a related tag indirection

      template <class T>
      struct result : result_algorithm<typename T::result_tag>
      {};

Is usually required for broken compilers anyway (if you care about
that sort of thing).

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com