Re: returning references
Michael DOUBEZ <michael.doubez@free.fr> wrote:
Daniel T. a 9crit :
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.
Since the lifetime of the object is managed by map<>, the returned value
references an internal state and it is clearly specified which
operations invalidate such objects: a call to clear() by example or
possibly a push_back in the case of vector<>.
Covered in my reply to James... 'vector' is an interesting case. The
vector is required to not invalidate the reference if at the time of the
call capacity() > size(). If that is not the case, then vector has some
control over the lifetime of the object referenced.
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.)
Technically, both are posible but a reference semantic would be counter
intuitive on a state you cannot change or share reliably.
As I said to James, this is a style issue. To me, returning by const
reference is a low level optimization over returning by object. So for
example, if 'size()' returned an object that was very expensive to copy,
I would use a const reference (or pointer to const) return rather than a
by value return and I would fully expect that clients of the class treat
it as if it was a by value return anyway.
[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.
That depends on the contract you have with Foo. If it is a singleton or
a scoped_ptr<> by example, there is nothing wrong.
Of course. The contract specifies control.