[boost] Re: call_traits

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-07-06 18:15:06

David Abrahams wrote:
> "Edward Diener" <eddielee_at_[hidden]> 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 ?