Tobias Schwinger wrote:
Hi Jonathan,
Next, function_type_signature is too complex; it has too many members, and their specifications are hard to understand. I would like to see separate metafunctions which take a function type and return
This impression come from the fact that the documentation is currently way too weak, especially at this point.
The primary interface of this class template is not to use most of these type member and use this class as an MPL Sequence (I'll cite a section of previous review discussion, which I hope explains this in more detail).
Most of these members are for optimization (saving template instantiations) so I vote for efficieny and not putting them into wrappers. Even though using the members of 'function_type_signature' directly is pretty close to the gory details, I don't think it should be an implementation detail.
<snip citation> I still don't quite understand it. Even if all the work is done by function_type_signature, can't you give it a more user-friendly interface -- perhaps a simple wrapper which hides the 'advanced' members? I will admit I haven't put a long time into studying 'function_type_signature'; my comments basically just reflect my impression that 'function_type_signature' is strange and complex.
1. the sequence of arguments; you might call this function_type::arguments
It already exists and is currently called 'function_type_parameters'.
Okay, sorry I missed it.
Btw. I prefer the term 'parameter' over 'argument' in this context, because a (formal) parameter constraints the argument (which is also called an actual parameter). I.e. (translated Standardese) the argument is what is passed for a parameter. I know e.g. 'std::unary_function::argument_type' -- but this is not exactly the same (I interpret it like: "please give me an argument of this type").
I, too, try to maintain the distinction between parameters and arguments. I'm not sure it's decisive here, though, since I usually think of a parameter as comprising a type *and* a formal name.
2. the sequence of arguments, including ant implicit 'this' pointer; you might call this function_type::effective_arguments
I've been thinking about this too already... This functionaliy has been requested by David Abrahams, already.
Alternatively, the result of instantiating the templates might themselves be sequences.
It's like this, already. You can either use e.g:
mpl::at< function_type_parameter<T>, I > mpl::at< function_type_signature<T>, I >
I understand; I was just saying that I thought function_type_signature was too complicated, and listing the functionality that I thought should be available one way or another.
Next, it's too hard too keep track of all the different tags, esp. remembering the order of the components of the names. Why not have a few atomic tags, and
I like the idea of atomic tags to query aspects instead of full combinations...
let user's combine them via inheritance? E.g.,
struct const_tag { }; struct volatile_tag { }; struct reference_tag { }; struct variadic_tag { }; struct stdcall_tag { };
struct my_tag : reference_tag, stdcall_tag, ... { };
..making this work with inheritance, in particular, might be inefficient. though (internally these are just MPL Integral Constant bit masks).
It involves an extra level of indirection. However, I think it could be done in a way that adds only a miniscule amount of compile time when using the built-in tags.
typedef is_function_type<my_tag, T>::type result;
You could define a bunch of convenience tags for common cases, but people wouldn't be required to learn them. This is what the iostreams library does.
This is a bit opposite to the suggestion to remove the dominant role of tags...
I don't see how this is opposite. Jonathan