Date: 2003-03-21 13:30:27
> -----Original Message-----
> From: Eric Niebler [mailto:neric_at_[hidden]]
> > > 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'm using the term "by value" to mean an abstract concept.
Let me see if I can rephrase my point of view:
If you store an "int", you are storing a number.
If you store an "int &", you are storing a modifiable reference to a
number that is located somewhere else.
If you store "int &", and return "int", you have not transferred the "by
value" abstract concept -- that is, the return value is just a number, not a
modifiable reference to a number located elsewhere. [ In this case, you
have "lost value", so to speak. Heh, heh... :) ]
Whereas, if you store an "int", then you can return by value ("int") or by
reference ("int &").
> I don't doubt that there is a use for the current implementation. What
> 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.
Again, Standard practice generally doesn't apply here, since they just
ignore references completely.
I think that std::vector<int &>::value_type -- if it existed -- would be
My point is that if an algorithm wanted to work with a type that is either a
reference or non-reference, then it *should* use call_traits<T>::value_type
for all temporary variables. And in this case, the "int &" would be the
E.g., if an algorithm existed that would return one of the values in a
hypothetical container of references, would you want it to return "int" or
> I suspect that this is the more common usage
> scenario (<-- blind asseriton), and it is the behavior people
> would expect.
Most generic software I'm familiar with follows the Standard guideline of
"do not use with reference types". There are a few exceptions to this rule,
e.g., compressed pair. These reference-friendly components have made up the
rules as they go, in the way that made the most sense to the authors at the
> Since there is a need, as you say, for a typedef that can be used to store
> type T and/or return it, perhaps there should be a different typedef, like
> "member_type" or "return_type" (or both!).
I agree with this totally; I like the idea of two names other than
value_type. However, I think that they should both resolve to the same type
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk