Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-19 15:03:18

Tobias Schwinger wrote:
> Hi Jonathan,
> Jonathan Turkanis wrote:
>>Here's my review of the function types submission. I'm sorry I waited until the
>>last minute to submit my review.
>>I vote to accept the library, even though I have some problems with the design.
> Thank you for your review and for the positive vote.
>>>What is your evaluation of the design?
>>My main criticism is that the metafunctions taking tags are given too prominent
>>a place in the library. I would rather have the library provide a collection
>>metafunctions to handle the most common combinations of tags and provide the
>>more generic metafunctions for 'advanced' use.
>>For example, I'd like to have metafunctions 'is_[plain_]function_type,'
>>'is_function_pointer,' 'is_function_reference' and
>>'is_const_member_function_pointer,' like I provided in the above mentioned
>>library, in addition to 'is_function_type.' Also, I'd like to see specialized
>>metafunctions for constructing (plain) function types, function pointers and
>>function references, in addition to the general purpose metafunction
> Basically a set of wrappers... I like it, especially in conjunction with Dave's
> request to put things into a sub namespace of boost. These expressive forms
> could go into boost (given they don't collide with TypeTraits) then.

Some more thoughts on this:

Having this sort of interface, I'ld like to put the tag after the other
parameter for the "advanced" functions taking a tag.

The "metafunctions for most common cases" (as proposed in the review) can be
implemented directly (rather than wrapping is_function_type) to save a template
instantiation, of course.

These would be candidates to be merged with TypeTraits. Something like this:

     // Pseudo code
     using boost::function_types::is_member_function_pointer // for example
     // highly portable code

would allow a smooth transistion.

I'm not really sure on the "fine grained metafunctions for type synthesis" part
of your suggestion, though. It's a pretty "advanced" use case, isn't it?
Putting the tag at the end of the template parameter list allows a default
parameter like 'plain_function', so we wouldn't need a tag in most cases:

     function_type<Sig>::type &
     function_type<Sig>::type *

Comments welcome!



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