From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-19 16:19:21
Hi Jonathan,
thanks for your response! My second reply to your review was sent almost
simultanously...
Jonathan Turkanis wrote:
> 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.
I really believe it's bad documentation that gives you this impression.
Some members can't be hidden because they make up the MPL-Sequence concept
('type', 'tag').
Other members provide essential information: 'kind' and 'representee'.
'types' is for optimization (not going through the decoration).
So the only member I could hide is 'arity', I guess.
Probably I should clearly point this out in the docs. By coloring, for example.
>>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.
>
An interesting way to look at it!
Doesn't entirely convince me since the argument only exists at the call site...
And because it's all about types, anyway - my thinking was something like: "You
can't know the argument's type - you can only know the one of the parameter".
>>>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.
>
Not entirely convinced design-wise either because it's quite error prone.
I like your idea of banning the tags from the primary interface, entirely - and
adding "aspect tags" only for querying.
Most cases of synthesis can work "tagless" by swapping the 'Tag' and 'Types'
parameter of 'function_type', defaulting to 'plain_function', as described in my
second reply to your review.
>>>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.
>
We already put the convenience cases in seperate metafunctions, don't we?
Having "atomic tags" (or let's call them "aspect tags") for querying,
cv-qualification as part of the class type, common case metafunctions we'ld
barely ever need to use them.
My next post will be a summary of what I think could be a reasonable synopsis
(based on review comments and on my own experience from having used the library
in several different places now).
Regards,
Tobias