Find pointer of object in vector C++

Question

I have a class which is called Position:

class Position
{
    public:
    ... //Constructor, Destructor, ...

    private:

      signed int x_;
      signed int y_;
}

Then I have a vector which stores pointers of Positions:

std::vector<Position*> positions

How can I check if a Position is contained in the vector? For example, I have an object of a Position:

Position* p_ = new Position(0, 0);

And I want to check if the vector contains a Position with the same coordinates? Which operator do I have to overload?

Thanks, Barbara

Answer 1

auto it = find_if(positions.begin(), positions.end(), 
                 [=](position* p)
                 {
                    return p->x() == p_->x() && p->y() == p_->y();
                 });

if(it != positions.end())
{
       //object found
}

However, unless you have a real reason to store pointers in the vector (e.g. you're going to use polymorphism), storing objects directly is much simpler.

vector<position> v;
v.push_back(Position(1, 2));
...
Position p_(1, 4);
auto it = find_if(v.begin(), v.end(), 
                  [=](position p)
                  {
                      return p.x() == p_.x() && p.y() == p_.y();  
                  });
if(it != v.end())
{
   //position found
}

In the latter case it is possible to further simplify the code by overloading operator == for position.

bool operator == (position p1, position p2)
{
   return p1.x == p2.x && p1.y == p2.y; //assuming operator == is declared friend
}

Then you can

auto it = find(v.begin(), v.end(), p_);

Answer 2

Add this to class Position

Public:
bool isSamePosition(position * p){
    return p->x == this->x && p->y ==this->y;
}

Then compare with all in the vector

bool unique = true;
for (int i = 0; i < positions.length(); ++i){
    if (new_position->isSamePosition(positions[i])
        unique = false;
}
if (unique==true)
 //do something like push_back vector
;

Answer 3

And I want to check if the vector contains a Position with the same coordinates? Which operator do I have to overload?

If you had a vector of positions (instead of vector of pointers to positions) the operator you'd have to overload would be:

bool Position::operator==(const Position& p);

With this code, you could write (assuming you are using std::vector<Position> positions;, and not std::vector<Position*> positions;):

using std::find; using std::begin; using std::end;
const Position p{}; // element that is sought after
bool exists = (end(positions) != find(begin(positions), end(positions), p));

[comment:] Yeah I am also quite unsure about this. I asked one of my teammates why he does this [i.e. store by pointers] and he said it would be more efficient and faster and it should not be changed - EVER.

It is probably not more efficient, nor faster than storing by values. If you are not in a position to change the vector though, you will have to add the operator declared above, and also a predicate that compares a Position instance to the values in a Position pointer, and using that with std::find:

    const Position p{}; // element that is sought after
    auto matches_position = [&p](Position const* const x)
    {
        return x != nullptr // can positions in the vector be null?
            && p == *x;
    };

    bool exists = (end(positions) != find(begin(positions), end(positions),
        matches_position));

== Coping strategy ==

I would go for the first version (no pointers in the vector), by doing the following:

1. create a new (minimalistic) project, that fills two separate vectors, with a bunch of randomized positions (fixed number of positions, between 2000 and 10000 instances or so); the vectors should contain positions by pointer and by value respectively, with the same values in each position (a position should be in both vectors, at the same index)

2. perform the search for the same values in both vectors.

3. repeat the searches multiple times (to average and minimize timing errors)

4. take results to your colleague(s).

There are two outcomes from this: either your colleague is right (which seems pretty unlikely, but hey! who knows?) or he is wrong, and his code that "should never be changed" - well ... it should be changed.