I'm about to refactor some duplicated code. Two functions both search in a multimap using equal_range(). In a for loop after the call to equal_range() there is a for loop that sets an iterator to equalRange.first with the condition it != equalRange.second.
If the correct value is found, the two functions differ. What I would like to do is to have the search function as an own help function used by the previously mentioned two.
Making that work is not the problem. What is the problem is that I cannot figure out a way to make it "easy" and future proof in a way that makes sense to other people using this code. Obviously, I would like something returned from the search function.
If I were to return a boolean to indicate if the value was found in the multimap, I would have to pass an iterator to the multimap which points out the element. I find that quite ugly.
If an iterator was returned instead, we of course have to check that against the boundaries back in the two functions that use the search function. We can't check it against multimap.end() since we use equal_range so equalRange.second doesnt have to equal multimap.end().
Using boundary checking returnIter == checkBound(x) where checkBound(x) returns multimap::upperbound(x) makes the checkBound(x) aware of the equal_range implementation of the search function. Hence, if someone else were to change the search function, the checkBound(x) might not work as expected.
My standing point here is that the users of the search function should not be concerned with how it is implemented, i.e., should not know that it uses equal_range.
What are your inputs and suggestions to this? Am I over-detailed here? How would you have implemented the search function?
Thanks