Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2003-03-21 09:03:11


> -----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 &".

> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk