Re: returning references
James Kanze <james.kanze@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
jkherci...@gmx.net wrote:
Daniel T. wrote:
James Kanze <james.ka...@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
A map does not return a non-const reference to any internal
state, so I don't see how that relates in any way.
std::map certainly does return references to internal state, as
does every other map I've every seen or heard of.
Really, could you give an example? Maybe I'm mistaken...
std::map< int, int > the_map;
...
the_map[5] = 6; // the_map[5] returns an int&.
I conjecture that the two of you are in disagreement about whether
that is an "internal state" of the map. Since I have no idea what
"internal state" is supposed to mean with regard to std::map, I
will not offer an opinion.
Right, that is not internal state, I define "internal state"
as state that is part of the invariant of the class. Does
changing the state of the object returned by map::operator[]
have any chance of breaking any of the map's invariants? No.
I'm willing to drop the whole thing, it's my style, but I still want to
cover the issue you bring up below.
But the fact that the element exists, in the map, is part of the
maps internal state. You can't change this via the reference,
but you can certainly change it via other functions, while the
reference is still present.
The key to the above sentence is "you". *You* (i.e., the client using
the map) can "change it", the map cannot do so itself. In fact, the map
is specifically forbidden by the interface to remove/add an object
unless directed by certain special functions, and specifically required
to remove/add one when directed. The fact that the elements exist are
not "internal state".
E.g.:
std::map< int, int > theMap ;
int& r = theMap[ 5 ] ;
theMap.erase( 5 ) ;
// ...
The presence or absense of the element in the map *is* part of
the map's internal state. And a reference to the element is
thus also part of the map's internal state, since it designates
something under control of the map.
I don't agree. The map has no control over when the client will call
erase, and it must do the erasure when the client does call the
member-function. The map doesn't control the lifetime of the object
anymore than your bank controls what you do with your money.