Boost logo

Boost :

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

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


> 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

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

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

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