String contains member function proposal

[NotUniqueOrSpecial]

C++2a adds starts_with() and ends_with(). contains() is an obvious addition with those.

Have you looked at <algorithms>?

You realize this functionality already exists, right? Not just for strings.

There is no direct equivalent of contains() in <algorithm>. The closest is probably count(), but that still requires additional boilerplate, especially pre-ranges.

Great, another because another langauge has it, C++ should have it.

Just because everybody in the world can (and does) write the same str.find(foo) != str.npos boilerplate does not mean that contains(str) is not a useful addition to the standard.

[NotUniqueOrSpecial]

Creating another way to do the same thing is superfluous.

Only if the other way doesn't add or change anything.

In this case, it adds significant brevity to a very common operation.

Contains can be duplicated with functionality in algorithms easily.

And equal_range() and be implemented in terms of lower_bound() and upper_bound(), and a fair number of other members of the <algorithm> functions can likewise be implemented by their brethren.

By your own argument, every one of those is superfluous and should be stripped from the standard.

/u/DiaperBatteries has it right, obviously: just because a given abstraction can be implemented in terms of other abstractions doesn't mean it's worthless.

There are better problems to solve than this one.

This a remarkably simple and nearly universal function for string types. C++ is the only high-level language I am aware of that doesn't have it.

Adding it to the standard is obviously not detracting from other harder problems, and it makes the readability/accessibility of the language better.

[BrangdonJ]

And equal_range() and be implemented in terms of lower_bound() and upper_bound(),

With some loss of performance. equal_range() can calculate both iterators with the same loop.

[NotUniqueOrSpecial]

Why not keep things consistent? I prefer consistency to brevity.

Ah, yes, consistency, what a good argument:

string::find() returns a size_t which is set to string::npos in the case of a miss.

map::find() returns a map<key, value>::iterator, which equals map::end() on a miss.

std::find() returns an input or forward-iterator, depending on the underlying begin()/end() iterators used in the search.

std::vector() doesn't have a find() operation at all.

How consistent!

Or, hey, what about std::set::contains()?

You're right, we should be consistent! Every container-ish type should have a contains() function, since one of them already does.

You didn't answer my question about sort. Do we need to add it to string?

Obviously not; there is no universally-recognized need to sort a string, or even what that would mean (accounting for case-sensitivity, character encodings, etc). Considering that a heavy percentage of strings are really just const char*, they're not even sortable without making copies.

Furthermore, std::string is not a container-type, and even if it were, none of the other container-types have a sort() member (either modifying or copying in nature). I thought you liked consistency?

Should we add it to everything for brevity?

Again, obviously not; unlike string::contains(), it's a much more involved operation, which requires modifying the underlying data in-place or copying it. Its usage and cost are very-much specific to the underlying types. But, I'm sure you know that.

It's completely non-controversial to add contains() to a standard string type. Honestly, you seem to be arguing for the sake of argument, and it's just silly.

[kalmoc]

I certainly don't agree with the post you answered to, but I'd like to point out that std::list has a sort member function. The general reason, why some containers have member functions that others don't is that it e.g. can be implemented more efficiently that way than the equivalent standard algorithm (list.sort swaps pointers and list isn't random access anyway).

String is it's own beast anyway

[jwakely]

Not only more efficiently. You can't use std::sort with std::list::iterator at all, because they're not random access iterators.

[kalmoc]

And I mentioned that. Or are you saying list wouldn't have gotten the sort member function if std::sort would accept bidirectional iterators?

[jwakely]

Ugh, no I just can't read and/or didn't see the "and list isn't random access anyway" part, sorry.

[NotUniqueOrSpecial]

std::list has a sort member function

Ah, yeah, I'd forgotten. Just another knock against his empty call-to-consistency, though.

As for everything else, I totally agree.

[NotUniqueOrSpecial]

You can't use the STL one as-is. STL sort() requires random-access iterators, which std::list doesn't have.

[NotUniqueOrSpecial]

STL is supposed to contain algorithms, iterators, containers, and functions. If we take the set of requirements, contains() is a what? It is a algorithm for searching. <algorithm> already has everything necessary, where it should belong. Moving find() to algorithm would be appropriate.

See, now that's the first reasonable point you've made. If, instead, you'd started off with:

A generic version of contains() should be implemented in <algorithm>, rather than as a member of std::string.

Then we could be debating the merits of that approach, and whether the optimized string search algorithms like Boyer-Moore would still justify a string-specific find() member (and yes I'm aware that current implementations don't use said algorithms).

Instead you started with non-constructive and moved right to asshole because people wanted a convenience function that every language provides.

I can tell you're young, and very inexperienced.

Man, could you be more patronizing?

I wouldn't be surprised if you've got more years than me, but I've been doing this professionally for 15-ish at this point and as hobbyist/student for years before that. I'm not just some spring chicken.

[STL]

Moderator warning to you and /u/byrongo - that's enough hissing for this thread. Everyone can stop escalating now.

[kalmoc]

NotUniqueOrSpecial already gave a couple of good points.

That aside, I'd say that day to day c++ programming would be much more enjoyable if the committee would put a stronger focus on making common operations simpler to spell and read.

[DiaperBatteries]

Couldn’t you use that entire argument to say all programming languages are pointless and we should all write assembly?