Jody Hagins wrote:
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.
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