
David Abrahams wrote:
"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.
By assume I meant that the documentation basically divides its explanation between user-defined types and built-in types. Since pointers and references to functions fall under built-in types, I follow the documentation about built-in types and I have my answer. There is a question of interpretation. So you ask the question and hopefully one of the original implementors gives you an answer.
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.
Here it is even clearer from the documentation that a POD class follows the rules of a user-defined type. You are attempting to twist the word "assume" for your own purposes.
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?
You are trying to win debates instead of finding out answers.
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.
How does one work with them in the context of call traits ?