I'll have to answer this upside down: Jody Hagins wrote:
On Wed, 08 Jun 2005 02:39:25 +0200 One of my mottos is: "If you don't want me to do it, don't provide the interface." Around here, I am known for "breaking" code the first time I use it, because I seem to automatically see uses that were not necessarily intended... it also explains some of the reasons I am so pedantic about docs.
So I can be happy to benefit from your "quality assurance instinct" ;-). In fact, I was (and still are) unsure if the members of 'function_type_signature' should be documented at all. The primary interface for type analysis (clasification & decomposistion), is_function_type function_type_arity function_type_result function_type_class function_type_parameter* and all MPL-Sequence operations (called "Intrinsic Metafunctions" in its docs which means things as: front, back, at, ...) are built upon one single class: function_type_signature Therefore, all these members have at least an internal right to exist. I did document them "just in case", because there might be some corner-cases in which their use is more efficient or convenient. It seems safe to remove them from the documentation to me ITM, but I want to think some more about it before doing so. Another option could be to move their description to a comment in the header. If they are kept, however, I see the documentation should be changed to make a very clear recommendation not to use them, unless having good reasons.
Tobias Schwinger <tschwinger@neoscientists.org> wrote:
[...]
Hmmm. Kinda like getting the most derived type when calling typeid on an instance of a polymorphic class. Interesting. I'm not sure how much I like that, but I'm not sure about the alternatives either...
It's used internally by 'is_function_type' (to match it against the tag specified by the client) and by the Sequence operations (to reconstruct the type after the Sequence has been modified). I guess this gives you an idea why you get the "most specialized" tag.
Curious question: what's the intention behind this ?
I dunno. I just thought it was a possible use of the interface. However, one of the thoughts was that I do not necessarily know the tag, but I have a type. Maybe something like iterating through a collection of types, looking for types that are elements of the same type-tag set, so that I can perform some action (like registering that type with some multi-signal mechanism).
OK, let's say we want to register a whole bunch of functions. This implies that we are either using Fusion-tuples (or alike) or pointer (to member) non-type template parameters, because the type of a pointer (or reference) is not enough to describe a function we can call. For sorting, a custom comparator gives you the flexibilty to define whatever ordering you like. A simple scenario could be something like this: A vector of tags for the groups and a binary metafunction that compares the index of the first match (found by applying is_function_type) in this vector for each parameter as the comparator. However, if your only criterium for sorting is the type-tag you might be better off with filtering, anyway. In fact, I'm not convinced that sorting is appropriate here at all: it seems to me like a case for making decisions inside the iteration on a per-function basis on which runtime code, dispatch identifier, map entry, etc. to use (and make sure similar functions end up in the same pot, somehow ;-) ). Generally, I believe there are still lots of interesting design opportunities in the direction of "intelligent callbacks facilities" (and the library we're talking about here is another puzzle piece for their implementation). Thanks again for spending so much time evaluating my submission. Regards, Tobias