David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
David Abrahams wrote:
<snip>
is_function< T, unspecified_decoration >::value // true for any type T that the library can handle
[You need to say more clearly what "can handle" means. IMO the comment should really be expressed as the last sentence of the foregoing paragraph]
s/type the library can handle/(possibly decorated) function type/
"(possibly decorated)" adds nothing. You have already made it clear that function types can be decorated -- or if you haven't, you can't just throw the term in here in parentheses and expect anyone to understand what you mean.
What 'decorated' means was already introduced (by the very first sentence of the documentation, see previous post).
Generally I agree. However in this case it /should/ be mentioned because:
template<typename T, typename Tag = undecorated> struct is_function; ^^^^^^^^^^^
The default argument, if no tag is given, makes 'is_function' only match function types (standard definition, compatible with TypeTraits).
The "code-to-English-mapping" is like this:
is_function<T> // "is T a function (not decorated)?" is_function<T,pointer> // "is T a function pointer?" is_function<T,variadic> // "is the function _in_ T variadic?"
I am unsure that supporting this default is well-advised.
Me not either that's why I came to the following conclusion: Hide the decoration property from the interface and put it in traits classes. So you only have specify the tag to ask for attributation, such as a particular calling convention or whether it is variadic (matching any by default). // Result: bool, Concept: MPL-Integral Constant template<typename T, typename Tag = no_attributes> struct is_function; % % struct is_function_pointer; % % struct is_function_reference; % % struct is_member_function_pointer; % % struct is_callable_builtin; // any of the above % % struct is_callable_scalar; // any except undecorated % % struct is_nonmember_callable_builtin; // any except member pointers % % struct is_nonmember_callable_scalar; // function pointer or reference For the full synopsis see: http://lists.boost.org/boost/2005/07/29657.php Btw. would be awesome if you can afford the time and work to skim over it!
We already have is_function in the Type Traits library, no?
John and I agreed on that an ultimate goal to make them the same template. The only question left is whether the mere presence of a default argument hurts. See also: http://lists.boost.org/boost/2005/06/29297.php
However, if too confusing I can introduce a version of 'is_function' with a single template parameter, change the name of the current 'is_function' to something else (e.g. "is_function_of_kind" -- better names are very welcome) and change its default argument.
has_properties?
I assume you are in some nice nested namespace of Boost, with that suggestion.
Probably not necessary based on what the answer to that question (previous paragraph of this post) is. <snip>
Requirements: one wildcard to match any decoration /or/ to change the default argument of the class template currently called 'is_function' (as described above)
Yes, that would be fine.
Same question here: which one of the two possibilties? <snip>
Here the properties of the original types are overridden in an implicit tag combination with the tag representing the type.
Well, we /could/ only allow it in this very context,
Allow what?
Sorry: "allow overriding of tag properties".
I'm lost, sorry. Too much context is gone.
I explained it again in the longest paragraph of this post: http://lists.boost.org/boost/2005/07/29669.php Thanks, Tobias