Boost logo

Boost :

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

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
>>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
>>>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).



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