why both value_type and reference

[Andrew]

Hello:

Can someone please elaborate on why the member types 'value_type',
'reference', and 'const_reference' are all defined in a standard STL
container. Why not just define
'value_type' and then use 'value_type&' and 'const value_type&'.

Also, if we define these other types, why not define
'const_value_type', etc....

Thanks,
AKH

 

[Victor Bazarov]

Can someone please elaborate on why the member types 'value_type',
'reference', and 'const_reference' are all defined in a standard STL
container. Why not just define
'value_type' and then use 'value_type&' and 'const value_type&'.

If you'd like you're free to use 'value_type&'. Nobody's to stop you.
The standard containers do not typedef 'reference_type' to 'value_type&'
because in some cases 'reference_type' is a special *proxy* type, and
not a simple C++ reference.

Also, if we define these other types, why not define
'const_value_type', etc....

Because that would be excessive.

V

 

[Andrew]

If you'd like you're free to use 'value_type&'. Nobody's to stop you.

Client's perspective:
If the designer of the container is using a proxy, shouldn't I use
'reference_type' instead?

The standard containers do not typedef 'reference_type' to 'value_type&'
because in some cases 'reference_type' is a special *proxy* type, and
not a simple C++ reference.

Library designer's perspective:
How does the designer of a container ensure that such a proxy type will
be used if the client could inadvertently use 'value_type&' instead?

I suppose to be on the safe side one should *always* use
'reference_type'
instead of 'value_type&', although that appears to be an easy oversight
if
one uses typedefs heavily. Could you please give me an example in the
STL
where reference_type is neccessary.

Thanks again for the quick reply,
AKH

 

[Pete Becker]

Hello:

Can someone please elaborate on why the member types 'value_type',
'reference', and 'const_reference' are all defined in a standard STL
container. Why not just define
'value_type' and then use 'value_type&' and 'const value_type&'.

Originally, it was because under 16-bit windows, pointers and references
could be qualified with "near" and "far", to reflect where the actual
data resided. If you had a container that stored its data in a way that
required far pointers and far references and the program was compiled
with the default set to near, then value_type* and value_type& wouldn't
work.

More generally, allowing the pointer type and reference type to differ
from the defaults allows more general memory management schemes.

 

[Victor Bazarov]

Client's perspective:
If the designer of the container is using a proxy, shouldn't I use
'reference_type' instead?

There is no answer to your question without any context. Both have the
right to exist because both are used, in different contexts. If you need
a reference to the type that is the stored value, use 'value_type &'. If
you need a way to modify the stored value directly, most likely you need
to use 'reference_type'.

What book on the Standard Library are you reading that doesn't explain
those things?

Library designer's perspective:
How does the designer of a container ensure that such a proxy type will
be used if the client could inadvertently use 'value_type&' instead?

There is no protection against stupidity.

I suppose to be on the safe side one should *always* use
'reference_type'
instead of 'value_type&', although that appears to be an easy oversight
if
one uses typedefs heavily. Could you please give me an example in the
STL
where reference_type is neccessary.

vector<bool>.

And get yourself a copy of "The C++ Standard Library" by Josuttis.

V