Unlike std::map and std::hash_map, corresponding versions in Qt do not bother to return a reference. Isn't it quite inefficient, if I build a hash for quite bulky class?
EDIT
especially since there is a separate method value(), which could then return it by value.
Weird, yes.
Perhaps this is because of the desired semantics, where doing e.g. value() on an unspecified key, returns a default-constructed value of the proper type. That's not possible using references, at least not as cleanly.
Also, things like name return value optimization can lessen the performance impact of this design.
Actually, some of the methods do return a reference... for example, the non-const version of operator[] returns a T &.
However, the const version of operator[] returns a const T. Why? As "unwind" has already noted, the reason has to do with what happens when the key does not exist in the map. In the non-const operator[], we can add the key to the map, then return a reference to the newly added entry. However, the const operator[] can't do this because it can't modify the map. So what should it return a reference to? The solution is to make the const operator[] return const T, and then return a default-constructed T in the case where the key is not present in the map.
const subscript operators of STL containers can return a reference-to-const because they flat out deny calls to it with indexes that do not exist in the container. Behaviour in this case is undefined. Consequently, as a wise design choice, std::map doesn't even provide a const subscript operator overload.
QMap tries to be a bit more accommodating, provides a const subscript operator overload as syntactic sugar, runs into the problem with non-existing keys, again tries to be more accomodating, and returns a default-constructed value instead.
If you wanted to keep STL's return-by-const-reference convention, you'd need to allocate a static value and return a reference to that. That, however, would be quite at odds with the reentrancy guarantees that QMap provides, so the only option is to return by value. The const there is just sugar coating to prevent some stupid mistakes like constmap["foo"]++ from compiling.
That said, returning by reference is not always the most efficient way. If you return a fundamental type, or, with more aggressive optimisation, when sizeof(T)<=sizeof(void*), return-by-value often makes the compiler return the result in a register directly instead of indirectly (address to result in register) or—heaven forbid—on the stack.
The other reason (besides premature pessimisation) to prefer pass-by-const-reference, slicing, doesn't apply here, since both std::map and QMap are value-based, and therefore homogeneous. For a heterogeneous container, you'd need to hold pointers, and pointers are fundamental types (except smart ones, of course).
That all said, I almost never use the const subscript operator in Qt. Yes, it has nicer syntax than find()+*it, but invariably, you'll end up with count()/contains() calls right in front of the const subscript operator, which means you're doing the binary search twice. And then you won't notice the miniscule differences in return value performance anyway :)
For value() const, though, I agree that it should return reference-to-const, defaulting to the reference-to-default-value being passed in as second argument, but I guess the Qt developers felt that was too much magic.
The documentation for QMap and QHash specifically say to avoid operator[] for lookup due to the reason Martin B stated.
If you want a const reference, use const_iterator find ( const Key & key ) const where you can then use any of:
const Key & key () const
const T & value () const
const T & operator* () const
const T * operator-> () const