On Tue, 07 Jun 2005 23:21:47 +0200 Tobias Schwinger <tschwinger@neoscientists.org> 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.
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.
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?
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>).
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. I am truly sorry for giving you the strange impression. Also, I appreciate your patience in the discussion. 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.