Re: [boost] [function_types]
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
Hi Steven, nice to hear from you, again. Steven Watanabe wrote:
Suppose I want to change a function's calling convention. function_type<components<int(...)>, tag<components<int(...)>, stdcall_cc> >::type
Actually, function_type< int(...), tag<components<int(...)>, stdcall_cc> >::type is equivalent and doesn't read too bad, does it?
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.
It might not be wise to throw out that feature. Currently cv-qualified function types are illegal, but it is likely they will be allowed in some contexts in the future (there is a defect report on that part of the standard). Further, these tags might come handy to work around BCC deficiencies.
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.
It's a cool idea, for sure! I'll pick it up in case I can eliminate all tag types except calling conventions (maybe by exploiting cv-keywords as mentioned in reply to Doug Gregor - but the syntax in that post is too irregular for my taste, still). Regards, Tobias
participants (2)
-
Steven Watanabe -
Tobias Schwinger