Title
hash should be std qualified for unordered container
Status
nad
Section
[unord]
Submitter
Pete Becker

Created on 2011-02-07.00:00:00 last changed 159 months ago

Messages

Date: 2011-02-25.00:00:00

[ 2011-02-25 Reflector discussion ]

Moved to Tentatively NAD after 5 votes.

Date: 2011-02-24.00:00:00

[ 2011-02-24 Chris Jefferson adds: ]

I recommend NAD, due to [contents] p3:

Whenever a name x defined in the standard library is mentioned, the name x is assumed to be fully qualified as ::std::x, unless explicitly described otherwise. For example, if the Effects section for library function F is described as calling library function G, the function ::std::G is meant.

Date: 2011-02-07.00:00:00

[ 2011-02-07 Howard Hinnant adds: ]

I think this is incorrect. We mean std::hash, though clients are free to specialize std::hash on user-defined types. With the possible exception of begin/end (which I'm not sure if we've settled that), swap is the only intended customization point (look up a function by ADL) in the std:: lib.

Date: 2011-02-07.00:00:00

[ 2011-02-07 Chris Jefferson adds: ]

I assumed (I might be wrong) it is because hash is designed to be a customisation point, like swap.

Date: 2011-02-07.00:00:00

Tom Plum pointed out to me that there's an apparent inconsistency in the std:: qualification of template names in the unordered containers:

 template <class Key,
           class T,
           class Hash = hash<Key>,
           class Pred = std::equal_to<Key>,
           class Alloc = std::allocator<std::pair<const Key, T> > >
   class unordered_map;

Is there a reason that hash is not qualified with std::? TR1 also does not use std:: here.

History
Date User Action Args
2011-02-25 16:08:15adminsetmessages: + msg5548
2011-02-25 16:08:15adminsetstatus: new -> nad
2011-02-24 22:27:25adminsetmessages: + msg5542
2011-02-07 14:20:34adminsetmessages: + msg5477
2011-02-07 14:20:34adminsetmessages: + msg5476
2011-02-07 00:00:00admincreate