"Edward Diener" <eddielee@tropicsoft.com> writes:
David Abrahams wrote:
But not all types, right? What about pointers and references to functions?
Good question but I would assume it is the same as pointers and references to built-in types.
One shouldn't have to assume.
What about POD classes the same size as 2 ints?
It is a user-defined type. I would assume it follows the rule for user-defined type since nothing was said in the doc about passing small user-defined types by value.
One shouldn't have to assume.
Not well enough for me, I'm afraid. What does "can not be used" mean? Will it generate an error?
I agree with this criticism of it.
Why is it unacceptable to assume some specifics here, but not in the two other cases I mentioned?
Note also: "If T is a small built in type or a pointer, then param_type is defined as T const, instead of T const&"
What is "small"?
I agree with this criticism also. I had assumed it referred to all built-in types, and ignored the "small", but this should definitely be explained.
It gives the values which call_traits will generate for any user defined type and various permutations of a basic type.
It's even less clear what fallback the library uses when a full implementation of call_traits would require partial specialization that isn't available.
I didn't just write this (it's from several posts ago); there's no need to repeat your earlier repetition of what's on the web page ;-)
"Note that for compilers that do not support either partial specialization or member templates, no benefit will occur from using call_traits: the
<snip>
It's also unclear to me what purpose is served by the "reference" and "const_reference" members.
In the beginning of the doc it specifies that both are for returning values of reference and const reference respectively, while avoiding the reference to reference problem.
boost::add_reference<T>::type boost::add_reference<boost::add_const<T>::type>::type
Too cryptic for me. Please explain.
These constructs do what you just described above and in fact they work even on compilers without partial specialization.
I am not defending call_traits itself, which I have not used but which I am thinking about using as part of my calling and returning style, but rather the doc which seems fairly clear to me about what it is and does from a user perspective.
It's still failing this potential user.
I think the areas you pointed out in the doc should be explained better but I still think the idea is a good one.
The basic idea might be OK but I think the execution is now very out-of-date. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com