I am building a text adventure and hit a snag.
I have classes PERSON, PLAYER, COP, & ENEMY.
Now PERSON is the main class, and PLAYER, COP, and ENEMY are all sub classes of PERSON
all of the function prototypes and definitions work except (2).

public:
   WEAPON* GetWeapon();
   void SetWeapon(WEAPON newweapon);

The two functions were first prototyped and defined in the PLAYER class and they worked well when I called them

void Battle(PLAYER* player){
    cout << "You are holding a " << player->GetWeapon()->GetName() << endl;
}

(I am assuming you understand that WEAPON class has a function GetName() and it returns a string)

However, I also wanted the COP and ENEMY to have them as well so I moved both the GetWeapon() and SetWeapon() functions over to the PERSON class since all 3 classes (PLAYER, COP, & ENEMY) are just inherited classes of PERSON. And this is when I started getting a [Linker error] undefined reference to 'PLAYER::GetWeapon()'
[Linker error] undefined reference to 'PLAYER:: SetWeapon()'

I am using an up to date version of Bloodshed Dev-C++ IDE
I have checked the spelling for any errors and found none in any of the function calls
I have doubled checked that argument types & return types all match but for the life of me can not figure out why I didn't get the error when the two functions were defined in the player class and DO get the error now that they are in the PERSON class which is a parent of the PLAYER class

Thanks for any help

Edited 6 Years Ago by drt_t1gg3r: n/a

WEAPON* GetWeapon();

WEAPON is a class, not a data type, and your declaring a function pointer? This doesnt make sense to me.

The PERSON creates the weapon that he holds

class PERSON{
private:
      WEAPON weapon;
public:
    WEAPON* GetWeapon(){
        return &weapon;
        }
     void SetWeapon(WEAPON newweapon){
     weapon = newweapon;
     }
};
class PLAYER : public PERSON{
private:
    //variables that only player has but not COP or ENEMY
public:
    //functions that only player has but not COP or ENEMY
};
void Battle(PLAYER* player)
int main(){
    PLAYER player;
    Battle(&player);
}
//use of function
void Battle(PLAYER* player){
   cout << "You are holding a " << player->GetWeapon()->GetName() << endl;
}

it returns a pointer to the weapon he holds so that I can display the stats of the weapon. The WEAPON class is a child of the ITEM class where GetName() is defined but those functions do not have any problems. And the (2) functions in question did not have any problems when they were first defined in the PLAYER class. They worked wonderfully. It is only when I deleted them from the PLAYER class and moved them to the parent class of PERSON

Edited 6 Years Ago by drt_t1gg3r: n/a

Well I did a work around. Instead of having the (2) functions in the PERSON class, I put them in each of the PLAYER, COP, and ENEMY classes and everything linked fine. I wonder if it's a Dev-C++ IDE thing. I can't understand why I can't have the (2) functions in the parent object and have the child objects call those functions.

Well I did a work around. Instead of having the (2) functions in the PERSON class, I put them in each of the PLAYER, COP, and ENEMY classes and everything linked fine. I wonder if it's a Dev-C++ IDE thing. I can't understand why I can't have the (2) functions in the parent object and have the child objects call those functions.

I can't imagine it has anything to do with Dev C++. You shouldn't need to do a workaround. It's fine to put the WEAPON variable and the getter and setter in the PERSON class and access them from a PLAYER, COP, or ENEMY object. It's the whole point of polymorphism.

Haven't gone over your code in detail, but skimming it, nothing jumps out as illegal, so perhaps there's a problem in code you haven't posted.

But almost certainly it has absolutely nothing to do with Dev C++.

Well Here is the whole project so far. It has the work around in it.

I see a link to some website. Where's the project? Just upload it here. The workaround won't do us much good, because it works. You need to upload the one that doesn't work. Or both.

This article has been dead for over six months. Start a new discussion instead.