From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-06-07 17:13:42
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.
> 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.