Re: [boost] [function_types]

From: Richard Smith (richard_at_[hidden])
Date: 2006-11-17 07:32:23

Tobias Schwinger wrote:

> Now folks complain more about the tags than before. Worse
> than that, I haven't been presented a single clearly
> superior alternative!

What's wrong with separate traits for these?  So far as I
can see, you only need four (plus one per platform specific
calling convention):

  is_variadic<T>::value
  is_const_member_function<T>::value
  is_volatile_member_function<T>::value
  is_default_cc<T>::value

These seem much more in the spirit of the existing type
traits in Boost.

By your own admission, "typical use cases will not require
that a tag argument is ever given *by design*", so requring
a library user to use mpl::and_ (and perhaps mpl::not_) to
fold these in on those atypical use cases that require this
information can't be much of a burden.

--
Richard Smith
> Steven Watanabe wrote:
>
> > I think that components should probably integrate
> > all the properties a little better.  Instead of making
> > it the union of a tag and an mpl sequence would it
> > be better to make it more like mpl metaobjects
> > with appropriate mutators:
> >   typedef components<void(int, char)> c;
> >   typedef set_result<c, bool>::type c1
> >   typedef set_param<c1, 0, const int&>::type c2;
> >   typedef make_variadic<c2>::type c3;
> >   typedef get<c3>::type f; // is bool(const int&, char, ...)
> > (Although maybe set_param is asking too much since I don't
> > see the corresponding operation in mpl.)
> > and querying metafunctions:
> >   typedef is_variadic<c>::type b;  //inherits from mpl::false_
> > These could be overloaded to take callable builtins too,
> > but that might cause too much overhead translating
> > back and forth between two representations.
>
> It seems a bit arguable to me whether we're talking about
> sugar or clutter, here.
>
> > For both components and the synthesis metafunctions,
> > having the result type as the first element of the sequence
> > doesn't really make sense to me.  I would expect that
> > the return type would often need to be handled separately
> > from the parameters in the cases where anything other than
> > simply passing the result of components to function_type<...>
> > is needed.
>
> I found it preferable to have a one-type representation,
> but I'm currently not feeling to strong about it anymore.
> Your proposal might be a good idea -- I'll think about it.
>
> Here is one scenario where the current design seems quite
> helpful, though:
>
>     http://tinyurl.com/whkmd (message thread on g.c.l.boost.user)
>
> >
> > I would like a way to find out what
> > a tag is composed of. I saw represents<> in the code
> > but it isn't documented (unless I missed it)
>
> Unlike in the previous version, and as stated above, the
> tags intentionally play a very subordinate role in the
> interface, so I left out 'represents' and 'extract' for
> the lack of real world use cases.
>
> > I compiled the following on all the compilers I have with different
> > values for N_TYPES.
>
> > note that this only uses one partial specialization
>
> It doesn't matter much! The compiler has to instantiate
> over 3000 templates for N_TYPES == 40. During template
> instantiation the compiler has to check which partial
> specialization definition matches. You are using over 3000
> distinct types so it will have to find out over 3000 times
> (even if it ends up picking the same definition, over and
> over again), looking at all specializations there are, of
> course.
>
> <snip code & benchmarks>
>
> I'm really glad to see that things compile with
> Codewarrior, since I don't have this compiler and thus
> never tested the library with it ;-)
>
> > A few minor things.
> > pp_tags/master.hpp
> >     BOOST_STATIC_CONSTANT(bits_t, combined_bits =
> >       LHS_bits ^ RHS_bits ^ (LHS_bits & RHS_mask)
> >     );
> > works but seems obscure to me
> > would (LHS_bits & ~RHS_mask) | RHS_bits be clearer?
>
> Right. It's an artefact and used to be an optimization
> back when it read mpl::bitxor...
>
> > Here are the mistakes I made when I looked at the
> > documentation initially. If no one else runs into these don't
> > worry about it. It's probably just me.
> >
> > I thought ClassTransform applied to all the parameters
> > not just this.
> >
> > I didn't realize that components was a tag. I saw the
> > capitalized and linked
> > MPL <../../../../../mpl/index.html> - Front
> > <../../../../../mpl/doc/refmanual/front-extensible-sequence.html> / Back
> > <../../../../../mpl/doc/refmanual/back-extensible-sequence.html>Extensible
> > <../../../../../mpl/doc/refmanual/extensible-sequence.html>Random Access
> > Sequence <../../../../../mpl/doc/refmanual/random-access-sequence.html>
> > of all component types
> > and missed the trailing "... and property tag "
>
> This one got confused already, the documentation needs to
> be fixed at this point.
>
>
> Thank you for your review.
>
> Regards,
>
> Tobias
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
--
Richard Smith