tags:

views:

472

answers:

6

what's the alternative?

Should I write by myself?

+31  A: 

There is the std::find() algorithm, which performs a linear search over an iterator range, e.g.,

std::vector<int> v;

// Finds the first element in the vector that has the value 42:
// If there is no such value, it == v.end()
std::vector<int>::const_iterator it = std::find(v.begin(), v.end(), 42);

If your vector is sorted, you can use std::binary_search() to test whether a value is present in the vector, and std::equal_range() to get begin and end iterators to the range of elements in the vector that have that value.

James McNellis
The advantage to having `std::find` as a free function is that it will work over an in memory array, a `std::vector`, or any other container that can be traversed linearly.
Thanatos
You could "multi-thread" it though.
Hamish Grubijan
You would only see a constant factor improvement. Furthermore, it's outside the scope of what `std::find` does. (A multi-threaded find is not needed in most situations.) You could write a `parallel_find()` that worked very similarly, however, and would work over all containers that met some set of (fairly loose) requirements.
Thanatos
+2  A: 

Use std::find(vec.begin(), vec.end(), value).

And don't forget to include <algorithm>

Kotti
+6  A: 

Who told you that? There's is "find" algorithm for vector in C++. Ironically Coincidentally, it is called std::find. Or maybe std::binary_search. Or something else, depending on the properties of the data stored in your vector.

Containers get their own specific versions of generic algorithms (implemented as container methods) only when the effective implementation of the algorithm is somehow tied to the internal details of the container. std::list<>::sort would be one example.

In all other cases, the algorithms are implemented by standalone functions.

AndreyT
Sorry to nitpick, but what's so ironic about a find function being named "find"?
jalf
@jalf: I assume it was intended sarcastically...pointing out that the OP is complaining there is no "find" when there is "find" and a google search for "c++ find" returns the second result as a link to `std::find` on cplusplus.com
KevenK
So sarcastically calling something ironic... Man, that's deep. ;)
jalf
+19  A: 

The reason there is no vector::find is because there is no algorithmic advantage over std::find (std::find is O(N) and in general, you can't do better for vectors).

But the reason you have map::find is because it can be more efficient (map::find is O(log N) so you would always want to use that over std::find for maps).

R Samuel Klatchko
+2  A: 

what's the alternative?

The standard offers std::find, for sequential search over arbitrary sequences of like-elements (or something like that).

This can be applied to all containers supporting iterators, but for internally sorted containers (like std::map) the search can be optimized. In that case, the container offers it's own find member function.

why there is no find for vector in C++?

There was no point in creating a std::vector<???>::find as the implementation would be identical to std::find(vector.begin(), vector.end(), value_to_find);.

Should I write by myself?

No. Unless you have specific limitations or requirements, you should use the STL implementation whenever possible.

utnapistim
+1  A: 

Having a 'find' functionality in the container class violates 'SRP' (Single Responsibility Principle). A container's core functionality is to provide interfaces for storage, retrieval of elements in the container. 'Finding', 'Sorting', 'Iterating' etc are not core functionality of any container and hence not part of it's direct interface.

However as 'Herb' states in Namespace Principle, 'find' is a part of the interface by being defined in the same namespace as 'vector' namely 'std'.

Chubsdad
However, it is entirely appropriate for a container to provide its own `find` function _if_ it can provide one that performs better than the generic `std::find` algorithm (consider `std::map::find`).
James McNellis