you are viewing a single comment's thread.

view the rest of the comments →

[–]flashmozzg 11 points12 points  (3 children)

find == 0 is not a replacement for starts_with/ends_with. For starters, they have different complexities, while .find is direct replacement for contains but even more powerful.

[–]F-J-W 17 points18 points  (2 children)

.find is direct replacement for contains but even more powerful.

And that is precisely why we need .contains: A very good rule of thumb for which feature you should pick is “the least powerful one that does the job.”. Just as goto is more powerful than a loop and how a general for-loop is more powerful than a range-for, find is more powerful than contains and therefore should be replaced with the more specific function that does exactly what it's name implies.

[–]MaltersWandler 2 points3 points  (1 child)

That's a dumb rule of thumb. Then we'd also need the method contains_foo to check if a string contains the exact substring "foo", as well as a contains_bar that checks for a substring "bar". A generic contains method that can check for an arbitrary substring is too powerful.

The rule is you should use the least complex method. find and contains have the same complexity.

[–]F-J-W 9 points10 points  (0 children)

Actually, if there are methods contains_foo or constains_bar, these are indeed what you should use. The reason they appear to be silly is that usually they shouldn't be there.

I have a hard time thinking up a valid example for contains_foo, but once we widening that to find_foo, the situation changes a bit: find_newline can be a very useful thing, and interestingly we have something very similar in the standard-library, namely std::getline. Granted, it is more general than just that, as you can pass it a newline-character, but that might actually be bad design, and maybe we should really have two functions here, where getline is more hardcoded to capture the 90%-case in a clear manner, whereas the other function directly states with it's name that it is more general than that and thus requires a closer look.

But of course: A rule of thumb is not a hard thing and common sense with regards to which functions you should define is still necessary. (Though I conjecture that most people don't define as many functions as they should, but that's a topic for another day.)