views:

156

answers:

4

Couldn't find_if just be an overload of find? That's how std::binary_search and friends do it...

+10  A: 

A predicate is a valid thing to find, so you could arrive at ambiguities.


Consider find_if is renamed find, then you have:

template <typename InputIterator, typename T>
InputIterator find(InputIterator first, InputIterator last, const T& value);

template <typename InputIterator, typename Predicate>
InputIterator find(InputIterator first, InputIterator last, Predicate pred);

What shall be done, then, with:

find(c.begin(), c.end(), x); // am I finding x, or using x to find?

Rather than try to come up with some convoluted solution to differentiate based on x (which can't always be done*), it's easier just to separate them.

*This would be ambiguous, no matter what your scheme is or how powerful it might be†:

struct foo
{
    template <typename T>
    bool operator()(const T&);
};

bool operator==(const foo&, const foo&);

std::vector<foo> v = /* ... */;
foo f = /* ... */; 

// f can be used both as a value and as a predicate
find(v.begin(), v.end(), f); 

†Save mind reading.

GMan
Huh? You're not finding the predicate. Based on your edit, it depends on the type.
0A0D
@0A0D: Does this clarify?
GMan
Yes. Made no sense the first time I read it. :)
0A0D
@Martin: By any chance, was that on IE? I normally don't use it, but I did once and noticed sub text was surprisingly tiny. I guess I'll have to stop that practice. :]
GMan
@GMan: Yep I am using IE this morning.
Martin York
@GMan - Yup. Forced to use IE at work here, and I saw a buch of way tiny text first time I read it too.
T.E.D.
@T.E.D: Hm, that sucks. :/
GMan
+1  A: 

It can't have the same name because there would be an ambiguity. Suppose that we had a find overload instead of find_if. Then suppose:

// Pseudo-code
struct finder
{
    bool operator()(const T&) const { ... }
    bool operator==(const finder& right) const { ... }
}

std::vector<finder> finders;

finder my_finder;

std::find(finders.begin(), finders.end(), my_finder);

The find would have no way to resolve the inconsistency: Should it attempt to find the finder in the container, or use the finder to do the find operation? To solve this problem they created two function names.

Mark B
A: 

You can certainly implement find in terms of find_if using some sort of equality predicate.

I would guess that the real reason is that you can implement find fairly easily and provide performant specialised implementations for typical encountered types; if you are using find_if, the predicate you pass in can be arbitrarily complex, which gives the library implementer less scope of optimisation.

Also, C++ has the philosphy of "you don't pay for what you don't use" and you'd normally expect that you don't want to pay for a predicate evaluation if a simple comparison will do.

Timo Geusch
The question isn't about implementing one in terms of the other, but why `find_if` isn't an overload of find that takes a predicate.
Mark B
+2  A: 

Here's what Stroustrup said (The C++ Programming Language, 18.5.2):

If find() and find_if() had the same name, surprising abmiguities would have resulted. In general, the _if suffix is used to indicate that an algrithm takes a predicate.

As to what exactly that "ambiguity" is, Steve Jessop answered that in his (top rated) answer to this SO question.

(note: that question may actually qualify as the same question as this one. I'm not quite smart enough in C++ arcania to decide).

T.E.D.
I'd call it related, since the question is different but the ideas are the same.
GMan