From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-08 09:06:17
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),
and all MPL-Sequence operations (called "Intrinsic Metafunctions" in its docs
which means things as: front, back, at, ...) are built upon one single class:
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
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_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk