From: David Abrahams (dave_at_[hidden])
Date: 2004-07-05 20:59:01
"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? What about POD classes the same size as 2 ints?
> 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?
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"?
> 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.
> 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.
>> 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.
> 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.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk