Re: [boost] [function_types]

From: Steven Watanabe (steven_at_[hidden])
Date: 2006-11-27 17:30:59

AMDG

Sorry for taking so long to reply.

Tobias Schwinger wrote:

> I don't see it this way: a function is a compound type and the mpl sequence contains the component types. They are ordered left to right which seems pretty common, too.
>   
OK. I understand now.  I had this kind of thing in mind:
function_type<
    mpl::push_front<
        result_type<F>::type,
        mpl::push_front<parameter_types<F>::type, int>::type
    >::type
 >::type
The outer push_front doesn't express the intent of the code clearly.

The mpl sequence is fine if it is just going to be created on the spot like:
function_type<mpl::vector<int, bool, char> >::type
For these cases what you have is as good as anything.
> I'm not sure I understand you correctly, here. To do what? Eliminate 
> the tags? ...
I suppose I should have been more clear. The thing I object to is
tag<...> not the individual tags. I don't see any way out of
using a type to represent the calling convention anyway.
>> > Neither
>> > one is completely satisfactory.
>> > 1.
>> >   template<class R, class Args, class Option1, class Option2, class Option3>
>> >   struct function_type :
>> >     original_function_type<typename mpl::push_front<Args, R>::type, 
>> > tag<Option1, Option2, Option3> > {};
>> > 2.
>> >   template<class ReturnTypeAndArgsAndTagsRolledIntoASingleType>
>> >   struct function_type : ... {};
>>     
> ... If so, I can't see any "tag elimination"... ... Both alternatives 
> even seem to increase the presence of tags in the interface ... I 
> considered the first alternative when redesigning the library, but I 
> chose the current design because it doesn't redundantly introduce lots 
> of rarely needed template parameters.
>> > 
>> > What about is_same<calling_convention<F>::type, fastcall_cc>?
>>     
> ... Same here: The return type of that metafunction would be a tag 
> again, wouldn't it? Maybe I just lost track because of a missing 
> sentence or something like that. Regards, Tobias

Suppose I want to change a function's calling convention.
function_type<components<int(...)>, tag<components<int(...)>, 
stdcall_cc> >::type
This is awkward even if the function to be modified is simple.
If on the other hand it is needed for a computed function type
where typedef is impossible e.g. a function declaration....
I believe this is one of the reasons MPL chose to pass containers
to algorithms instead of iterator pairs.

Now, about actually removing tags.

How often are the cv tags likely to be used? They are redundant
since for member functions this information is already available
in the first parameter.  If they are not a very common thing to
need, I would propose simply removing them from the interface.

If you stick to the MPL sequence representation, what about
adding the variable argument list onto the end?
function_type<mpl::vector<int, int, varargs> >::type
that way it looks more like the actual function type.

In Christ,
Steven Watanabe