Is there a reason that the std::map contains() function lacks a noexcept specifier?

Daniel

unread,

Jul 31, 2019, 10:10:24 AM7/31/19

to

The cppreference documentation doesn't identify any exceptions.

https://en.cppreference.com/w/cpp/container/map/contains

Thanks,
Daniel

Bo Persson

unread,

Jul 31, 2019, 12:12:54 PM7/31/19

to

The function itself is perhaps unlikely to throw any exceptions, but any
comparisons would use the Compare template parameter which is not
limited to noexcept operations.

Bo Persson

Öö Tiib

unread,

Jul 31, 2019, 5:55:39 PM7/31/19

to

On Wednesday, 31 July 2019 17:10:24 UTC+3, Daniel wrote:
> The cppreference documentation doesn't identify any exceptions.
>
> https://en.cppreference.com/w/cpp/container/map/contains

Hmm? Be constructive. How you suggest to define it then?
Let me try ...

bool contains( const Key& key ) const
noexcept(noexcept(key_comp()(key, key)));

That? Does that work?

Note that contains() is C++2020 map feature and C++2020 standard does
not exist yet. I don't even understand why to add it since it does
exactly same thing that std::map::count() already does. However
if it is possible to add such noexcept specifications then these
should perhaps be added to *lot* of other functions as well.

Daniel

unread,

Jul 31, 2019, 11:29:26 PM7/31/19

to

On Wednesday, July 31, 2019 at 12:12:54 PM UTC-4, Bo Persson wrote:
> On 2019-07-31 at 16:10, Daniel wrote:
> > The cppreference documentation doesn't identify any exceptions.
> >

> The function itself is perhaps unlikely to throw any exceptions, but any
> comparisons would use the Compare template parameter which is not
> limited to noexcept operations.
>

Thanks,
Daniel

Jorgen Grahn

unread,

Aug 1, 2019, 1:44:29 AM8/1/19

to

On Wed, 2019-07-31, Öö Tiib wrote:
...

> Note that contains() is C++2020 map feature and C++2020 standard does
> not exist yet. I don't even understand why to add it since it does
> exactly same thing that std::map::count() already does.

Probably to help us write more readable code:

if (employees.count(someone)) fire(someone);
if (employees.contains(someone)) fire(someone);

The latter reads better IMO. On the other hand, I think in 90% of
cases you want to find() the element so you can access it if it
exists.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Fraser Ross

unread,

Aug 1, 2019, 4:18:33 AM8/1/19

to

On 01/08/2019 06:44, Jorgen Grahn wrote:
> On Wed, 2019-07-31, Öö Tiib wrote:
> ...
>> Note that contains() is C++2020 map feature and C++2020 standard does
>> not exist yet. I don't even understand why to add it since it does
>> exactly same thing that std::map::count() already does.
>
> Probably to help us write more readable code:
>
> if (employees.count(someone)) fire(someone);
> if (employees.contains(someone)) fire(someone);
>
> The latter reads better IMO. On the other hand, I think in 90% of
> cases you want to find() the element so you can access it if it
> exists.
>
> /Jorgen
>

contains can stop after finding an equivalent element in a multimap or
multiset.

Fraser.

Öö Tiib

unread,

Aug 1, 2019, 6:04:54 AM8/1/19

to

On Thursday, 1 August 2019 11:18:33 UTC+3, Fraser Ross wrote:
> On 01/08/2019 06:44, Jorgen Grahn wrote:
> > On Wed, 2019-07-31, Öö Tiib wrote:
> > ...
> >> Note that contains() is C++2020 map feature and C++2020 standard does
> >> not exist yet. I don't even understand why to add it since it does
> >> exactly same thing that std::map::count() already does.
> >
> > Probably to help us write more readable code:
> >
> > if (employees.count(someone)) fire(someone);

Note that in actual code it can have non-confusing form like:

if (employees.count(someone)!=0) fire(someone);

> > if (employees.contains(someone)) fire(someone);
> >
> > The latter reads better IMO. On the other hand, I think in 90% of
> > cases you want to find() the element so you can access it if it
> > exists.
> >
> > /Jorgen
> >
>
> contains can stop after finding an equivalent element in a multimap or
> multiset.

Good catch!

Even there it can have same issue that empty() versus size()!=0 had.
The empty() is shorter and was cheaper for some containers but
programmers kept massively using size()!=0 (and its equivalents) so
committee had to require size() to be O(1) for all containers.
It is hard to figure why human brain works like that but programming
language has to support it to write efficient programs.