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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk