> -----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 &".
> Also, it runs contrary to standard practice. In several places in the
> standard library "value_type" is assumed to be a value, not a reference.
For
> instance, std::stack is defined as :
Standard containers place additional restrictions on their value_types, such
as Assignable, which references do not satisfy. A "value_type" is not a
concept, per se.
> Is this an oversight in call_traits?
Look at the "Examples" table in the call_traits documentation. If this is
not the behavior you want, use call_traits<int> (or, generically,
call_traits<remove_reference<T>::type>).
> Or just an unfortunately named typedef?
call_traits was originally designed to help the implementation of
compressed_pair. So the name "value_type" was used because it was the
natural name for the type of the members within compressed_pair. i.e., if
you wanted to declare a variable that could hold the requested value, it
would be of type value_type. The "value_type" member since then has become
commonly used as a return type for those types of values. I agree, it is an
"unfortunately named typedef".
-Steve
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
