[nly]

Well the containers that have fast lookup (set, map and their unordered_ and multi_ counterparts), all have efficient .find() member functions. The general philosophy of the idealised STL is not to provide you with anything you can compose efficiently yourself.

A 3-4 line template will will give you a terse boolean contains() method, but it won't give you any big-O guarantees, and having such a thing would encourage very inefficient patterns (like calling contains() and then doing a find() if it's true, which effectively does the lookup twice). Why introduce a weak abstraction? If you're forced to write it yourself you're more likely to understand the implications.

Alex Stepanov, who wrote the original STL, is very much a believer in fundamental indivisible building blocks like iterators and algorithms and careful API design. To grok more about why things are the way they are, I recommend watching his "Efficient Programming with Components" lectures[0]. Over the course he builds up, in excruciating detail, an implementation of merge sort, reasoning about, and discussing with his students, the implications of almost every line of code.

And yes, Stepanov complains about the lack of terseness and expressiveness in C++ as well.

[0] https://www.youtube.com/playlist?list=PLHxtyCq_WDLXryyw91lah...

[pcwalton]

There is a legitimate complaint with that specific example, though: having to write .begin() and .end() is obnoxious instead of using more modern iterators/ranges.

[nly]

well the slightly more concise way of writing it is this:

    auto e = end(container);
    if (e == std::find(begin(container), e, element)) { ... }

...but yeah, it sucks. If I were doing this though, i'd to be encapsulating things in to a higher level abstraction. Seeing std::find in more than 1 place in a file is a red light for me.

[rootlocus]

Holy cow, thank you so much for the lectures!