[boost] Re: [function types] Formal Review begins today.

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-07 19:39:25

Jody Hagins wrote:
> On Tue, 07 Jun 2005 23:21:47 +0200
> Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> 
> 
>>There is no runtime behaviour. If you violate preconditions you get an
>>error and  the library takes some effort to give you a nice one, too.
> 
> 
> I'm glad you spent effort to make sure the error messages were
> meaningful.  A lot of template errors require a team of CIA agents to
> decipher.
> 

I do not have anything against lengthy error messages, but I dislike lengthy 
error messages with their significant information somewhere in the middle (which 
is a problem when using static assertions away from where the actual problem is).

> 
> 
>>The "maximum standard", however, is a very subjective thing - and
>>existing  documentation of a library dealing with a similar topic may
>>serve as an orientation.
> 
> 
> Yup.
> 
> 
> 
>>No. This library only models the type system. Boost.Function (and
>>alike) should  be allowed to use this library in the future (as
>>higher-level components use  lower-level components not the other way
>>around).
>>
>>
>>However, here are two possible recipes of how a Boost.Function could
>>be analyzed  with this library:
> 
> 
> [snip ]
> 
> 
>>Right. The upcoming versions of these libraries and of course the ones
>>yet to  come should be encouraged to use this.
> 
> 
> I think you are suggesting that these other libraries use function_type
> in their implementation.  I'm suggesting that function_type should
> provide some extra support for them (especially boost::function) evan as
> a separate supplemental header file.
> 
>

I got this. Still, I think it is (by definition) and should be (in terms of 
abstraction) beyond the scope of this library.

Especially, I have something against this kind-of "overloading" the interface.

This is a good one for an example, especially because it can be done with 
relatively little code, IMO.

> 
>>>>You should not use it directly in 99% of all cases and use
>>>>
>>>>    is_function_kind<Tag, T>
>>>
>>>
>>>Hmmm.  I do not see this anywhere in the online documentation.
>>>
>>
>><CITE>
>>
>>  template<typename Tag, typename T>
>>  struct is_function_type;
>>
>></CITE>
>>
>>In fact it's in there two times ;-).
> 
> 
> Hmmm.  In your first email you used is_function_kind, to which I said it
> was not there, to which you replied that it is surely there, than proved
> it by showing that is_function_type was there.  Maybe the first was a
> typo?
> 

Shame on me ;-). Sorry for the confusion (it was called like this in earlier 
stages of the library).

> 
> 
>>>>instead. Actually there are no public functions to properly compare
>>>>the tags so  you should stay away from this.
>>>
>>>
>>>Actually, I was thinking of something more along the line of...
>>>
>>>	is_function_type<
>>>	    function_type_signature< foo_t >::kind,
>>>	    bar_t >::value
>>>
>>>though function_kind would be nicer...
>>>
>>
>>No - just simply: is_function_type<Tag,T>.
>>
>>There really should be a note that these members are there, because
>>they are  there and are not at all required for basic usage. It leads
>>to too much confusion.
> 
> 
> I still do not see how that gives me what I was looking for; checking to
> see if a function type (i.e., bar_t) is an element of the set described
> by the kind of another function type (i.e.,
> the_tag_type_of_function_type<foo_t>).
> 

OK - if that's what you are trying to do your code look good (in case you said 
this I must have overlooked it).

BUT: Careful here! The Tag contained in 'function_type_signature' describes the 
kind of function type as detailed as possible:

     is_function_type< function_type_signature< void(*)() >::kind
                     , void(*)(...) >::value

evaluates to 'false', because the tag given to 'is_function_type' is:

     non_variadic_defaultcall_function_pointer

while the tag computed from void(*)(...) is

     variadic_defaultcall_function_pointer

which is not a subset of the above.

Curious question: what's the intention behind this ?

> 
>>In most cases you won't need this class at all. Again, structuring
>>into two  sections may help.
> 
> 
> Sure, I think a restructuring may help in several areas.
> 
> 
> 
>>I must admit I had a strange feeling about the first rather fuzzy
>>post.
> 
> 
> I try to simply say what I think, but sometimes it does not come off
> quite right, especially in email.  

Never mind. I know this too well from a first-person perspective.

> I am truly sorry for giving you the
> strange impression.  Also, I appreciate your patience in the discussion.

You don't have to, as it turned out to be constructive.

> Hopefully, I can actually find some time to look at the implementation
> and try some examples myself, which would allow me to provide an
> official review.

This would be great (and it's probably motivating for you to hear that the 
actual implementation is quite small - only about 1500 lines incl. comments but 
without preprocessed files).

Thanks,

Tobias