More pointer woes.
Ok so i'm trying to build the member-function of the class that controls the movement of the enemies, and too implement some basic collision detection i want to pass it the address of the pointers of the player character and the enemies array that are on the heap.
so i tried prototyping;
and calling it with;
void move(Player * &thePlay, Enemy * &enemys);
but i get the error 444no matching function for call to `Enemy::move(Player*&, Enemy*)'
i'm sure the answer is obvious, but i don't know it!
Why do you really need the addresses of the pointers to do collision detection in the first place? You need the player data and access to the play area to do that. The location of the pointers which hold these things should be of no interest to you. Simplify!
This also makes no sense to me:
You are calling the function on an object in the array and pass the same array as an argument.
But the error also says that enemys (which is spelled enemies, btw) is not of the type the function expects. In other words, the prototype in this case is wrong. But you should follow citizen's suggestion, though, I think.
well the way i was doing it is to have the member function that moves them check to make sure that the move it comes up with is legal by checking where everything else in the level is then to just return true back to the main loop. that way the only thing the main loop is doing is calling the basic functions and passing pointers!
edit: i know it's spelled wrong, i just didn't feel like typeing the extra letters over and over again.
edit again: Ok i'll simplify. I should stop practicing to be a Microsoft programmer anyways.
Originally Posted by Terran
Oh, come on, is one letter extra too much for you?
It seems more like a spelling mistake than laziness ;)
BTW, since enemys is an array you can't pass it as a reference. If your design was correct you'd just have to change it to Enemy** (or Enemy* or Enemy*).
You could also change it to "Enemy *(&enemies)". It's better than Enemy*, since the 4 actually means something.
That's even more confusing.
Does the function really need to modify the enemy object? Otherwise a pointer might do.
Or better yet, a vector. Passing a vector by reference is no biggie.