Re: returning references
jkherciueh@gmx.net wrote:
Daniel T. wrote:
James Kanze <james.kanze@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.
Note, that the map class doesn't return a non-const reference from the
"size()" member-function. It could return either by value or by const
reference, either would be safe (assuming appropriate internal changes,)
and switching back in forth between them would not affect code that uses
map::size() in the slightest. (If it *did* affect code that uses the
member-function, the it is the calling code that is messed up.)
[What] if the client takes the address of [a const-reference]
return, and later uses it.
When James said the above, I took it to mean something like the example
below.
class Foo {
public:
const Bar& get() const;
};
void bad_client( Foo& foo ) {
const Bar* b = &foo.get();
// then do things, assuming that 'b' will continue to be
// valid no matter what I may do to 'foo'.
}
I consider such code to be inherently dangerous... When what is returned
is a const-reference to internal state, the calling code shouldn't
assume 'b's validity even past the ';' of the get call.