[boost] Re: call_traits

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-07-05 21:29:54

David Abrahams wrote:
> "Edward Diener" <eddielee_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> "Edward Diener" <eddielee_at_[hidden]> writes:
>>>
>>>> What are the issues with call_traits which make it unusable ?
>
> BTW, I should point out that I never claimed it was unusable.
>
>>> As far as I can tell, there is no clear documentation of what
>>> _precisely_ any partcular member of call_traits<T> is for a given T.
>>
>> The table given after "The following table shows the effect that
>> call_traits has on various types,
>
> 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.

>  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.

>
>> the table assumes that the compiler supports partial specialization:
>> if it doesn't then all types behave in the same way as the entry for
>> "myclass", and call_traits can not be used with reference or array
>> types" seems to answer that pretty specifically.
>
> 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.

>
> 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.

"Note that for compilers that do not support either partial specialization
or member templates, no benefit will occur from using call_traits: the
call_traits defined types will always be the same as the existing practice
in this case. In addition if only member templates and not partial template
specialisation is support by the compiler (for example Visual C++ 6) then
call_traits can not be used with array types (although it can be used to
solve the reference to reference problem)."

>>
>> See quote above. How many compilers without partial specialization,
>> beside VC6, does Boost really want to support anymore. My guess
>> would be 0 and if Boost didn't feel obliged to support VC6, I am
>> sure all Boost developers would be happier. I am not knocking the
>> tremendous effort Boost has made to support VC6, since I have used
>> it myself and am appreciative of it.
>
> This is probably all irrelevant to the OP because STLPort is trying to
> support many older compilers, unless something has changed over there.
>
>> But if
>> call_traits doesn't largely work with VC6 in any meaningful way, I
>> don't think it is a reason to deprecate it.
>
> Who said anything about deprecating?  Not a bad idea, though.

Mr. Gregor.

>
>>> It seems as though the documentation is intended to be a more
>>> abstract description of what happens, but it leaves me (at least)
>>> feeling very unclear about what I'm actually getting.
>>
>> Seems fairly clear to me. The only possibiliites not listed are
>> other permutations of user-defined types. I would think this latter
>> may be a documentation issue, but an educated guess would be that
>> other permutations of user-defined types would mirror the other
>> permutations of basic types.
>>>
>>> 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.

>
>> 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.