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