From: Eric Niebler (neric_at_[hidden])
Date: 2003-03-21 12:20:53
> > The way call_traits is currently implemented,
> > call_traits<int&>::value_type is an int&,
> > not an int.
> This is the correct behavior. If you are storing an "int &" and want to
> return it by value, you will return an "int &".
This is some new usage of the term "by value" with which I'm not familiar.
When I return an "int&", I call that return "by reference". ;-)
I don't doubt that there is a use for the current implementation. What I'm
saying is that calling it "value_type" is wrong because that term is used
already in standard C++, and with a different meaning.
call_traits::value_type should be like iterator_traits::value_type -- a
non-const, non-reference that can be used to store temporary variables in
algorithms and whatnot. I suspect that this is the more common usage
scenario (<-- blind asseriton), and it is the behavior people would expect.
Since there is a need, as you say, for a typedef that can be used to store a
type T and/or return it, perhaps there should be a different typedef, like
"member_type" or "return_type" (or both!).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk