> -----Original Message----- > From: Eric Niebler [mailto:[EMAIL PROTECTED] > > > > 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 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. 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 "int &". 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 correct type. 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 "int &"? > 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 time... :) > 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!). 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 (currently "value_type"). -Steve _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost