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
>> is the corresponding metafunction which computes the result type
>> based on the argument types. I think this is the most general
> 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.
>> The problem, of course, is that it is not terse.
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk