Add a cpl::contains(container, value) helper

[rouault]

and use it in gcore

@dbaston Thoughts? I'm quite tired of writing code like container.find(key) != containers.end(). As of C++17, we could use container.count(key), as the closest alternative to C++20 container.contains(key), but using count() might complicate future modernization when we bump to C++20. This cpl::contains(container, value) should be easily greppable to automate a change to container.contains(value)

[coveralls]

coverage: 69.298% (-0.003%) from 69.301%
when pulling 93ec1b7 on rouault:cpl_contains
into b6b5546 on OSGeo:master.

[dg0yt]

Hm, doesn't count always need to do too much? It cannot stop at the first match.

[rouault]

not for std::set and std::map, which are up to now the only users of that

[dg0yt]

not for std::set and std::map

... unless some call triggers the second overload of count? (Taking an "equivalent" key instead of an exact one.)

up to now the only users of that

This is a very generic function interface, but the implementation is specific. It gets attention (read: review) when added or modified. It is unlikely to get attention when a different use is added elsewhere. Including in software using GDAL.

[rouault]

Thanks for pointing me to this new C++14 second overload / "equivalent" key concept. I have a bit of a hard time fully understanding the impact of that , but my understanding of https://stackoverflow.com/questions/20317413/what-are-transparent-comparators, is that it is only available if you define something like a std::key or std::map specially constructed with a std::less<>, so that shouldn't occur with the current state of the code base. That said in #10518 I'm proposing to use a std::find() based implementation to avoid any performance issue.

It is unlikely to get attention when a different use is added elsewhere. Including in software using GDAL.

This can't as this is protected by a ifdef GDAL_COMPILATION. So for GDAL internal use only