Is it at all possible to change a single variable from a pointer?

[Tiger58]

I am stuck at a problem where I have two pointers pointing to the same object, and I need to change an int on one of the pointers but point to the same object.

To be more specific, there is an array of Item objects. A long list of items a player can buy. Then, there is the player's inventory, a vector pointer. Whenever a player buys an item, it sets the pointer to the bought object.

The problem arises when he buys two of the same object. I tried to identify the objects with an ID, but it does nothing, because they are just pointing to the same object, and so I have no way of telling them apart.

This is further complicated by the fact that it is a polymorphic object. So, I can't simply make a new every time I buy an object, without making a hassle. Well, at least I am not familiar with that kind of code just yet.

[upX86]

could you elaborate a little bit more:

The problem arises when he buys two of the same object. I tried to identify the objects with an ID, but it does nothing, because they are just pointing to the same object, and so I have no way of telling them apart.

Is player allowed to buy same object multiple times?

[Tiger58]

Yes, there is dual-wielding allowed, so he could buy for example two of the same sword.

My problem is that I made a long array of items that I want to keep static, for reference in the different shops, and so when a player buys an item I equal an inventory pointer to the bought item.

I was suggested the clone() function, would this work?

[upX86]

Hey Tiger58, saw your post: http://www.cplusplus.com/forum/beginner/118579/
I think it is the same.

I guess the problem arises when you do prepare the inventory with multiple vector objects pointing to same weapon object and deleting/modifying any one of them. Is it?

EDIT: typo

[Tiger58]

Yes, that is exactly the problem. Equipping for example, becomes troublesome since I identify the items by their ID, and when two items have the same ID it doesn't work as intended. And of course, I can't change the ID of one without changing that of the other, since I am changing the object of both pointers.

[upX86]

It could be done by Cloning and in clone function itself you can updated the ID and return the cloned object with different ID.

[Tiger58]

You saw my other post on the beginner forum, would it work the way I said, on my last post there?

[upX86]

when you are inserting items in vector, push cloned objecs like

weapon *clone1 = index[0]->clone(2);
inventory.push_back(clone1);

weapon *clone2 = index[0]->clone(5);
inventory.push_back(clone2);

and in clone function use setItemID(newID).

[upX86]

Yes, Exactly the same as I suggested

[Tiger58]

But do I have to do anything other than call the clone() function? Surely there is something else I need to do, doesn't it have to be declared manually? Is it already defined? The issue now is that I haven't really used clone before, I'm not sure what I have to code before I go around writing clone() freely.

[upX86]

you would have to write a clone function by you own, it can be like a copy constructor but the base class will have virtual declaration and implementation in derived class(es).

[Tiger58]

I want to do this right, because this program needs to be turned in soon. The following are the kind of classes I have.

class Item
{
  //Variables/Virtuals
}

class Weapon:public Item
{
  //etc etc
}

class Armor:public Item
{
  //etc etc
}

class Helmet:public Item
{
  //etc etc
}

class Boots:public Item
{
  //etc etc
}

How would I declare a clone() function for this? I tried looking it up but there are few references to it, and they aren't very clear as to what needs to be done.

[Tiger58]

Well, I tried the cloning thing, but it says I cannot instantiate abstract class.

[upX86]

Try this:

class Item
{
  //Variables/Virtuals
public:
  virtual Item* clone(int ItemID);
};

class Weapon:public Item
{
  //etc etc
  Weapon* clone(int ItemID)
  {
      Weapon *clone = new Weapon(*this);
      clone->setItemID(ItemID);
      return clone;
  }
};

class Armor:public Item
{
  //etc etc  
  Armor* clone(int ItemID)
  {
      Armor *clone = new Armor(*this);
      clone->setItemID(ItemID);
      return clone;
  }
};

class Helmet:public Item
{
  //etc etc
  Helmet* clone(int ItemID)
  {
      Helmet *clone = new Helmet(*this);
      clone->setItemID(ItemID);
      return clone;
  }
};

class Boots:public Item
{
  //etc etc
  Boots* clone(int ItemID)
  {
      Boots *clone = new Boots(*this);
      clone->setItemID(ItemID);
      return clone;
  }
};

I think this should solve the problem in your case.

EDIT: &this to *this

[Tiger58]

It worked! Thank you

[MikeyBoy]

A couple of things to note:

1) Should Item::clone() be pure virtual? Is there actually an implementation of Item::clone()? Or is this simply defining an interface that derived classes must implement?

2) Remember that you're dynamically allocating memory when you clone objects, and are passing the pointers back to the calling code. You'll need to think about who owns that memory, i.e. who is responsible for freeing it when it's no longer being used.

[upX86]

Great...

1) Should Item::clone() be pure virtual? Is there actually an implementation of Item::clone()? Or is this simply defining an interface that derived classes must implement?

Not needed to be pure virtual until the base class is not abstract class.
and as per my understanding there is not any implementation for clone method, it is just a type of design pattern. we are implementing clone as any other virtual member function.

2) Remember that you're dynamically allocating memory when you clone objects, and are passing the pointers back to the calling code. You'll need to think about who owns that memory, i.e. who is responsible for freeing it when it's no longer being used.

As we are returning the new memory to the caller, so it is caller's responsibility to delete/manage the allocated memory.

[MikeyBoy]

Not needed to be pure virtual until the base class is not abstract class.

I'm not saying it *needs* to be. I'm asking whether it *should* be. If there's no implementation of Item::clone(), and it's necessary for every subclass to implement it, then why not make it pure virtual? This is exactly the situation that pure virtuals are intended for, so using it is a clear indication to both the compiler and other users of the class that subclasses must implement the method.

What is gained by not making it pure virtual?

As we are returning the new memory to the caller, so it is caller's responsibility to delete/manage the allocated memory.

Well, yes, obviously. I'm reminding the OP that this is necessary, and prompting them to consider which part of the calling code has this responsibility. Who takes ownership of the memory pointed to by these pointers? The immediate calling function? Another class? Somewhere else?

These are important things to consider when allocating dynamic memory and then handing the pointers on, and I'm prompting the OP to consider them.

[upX86]

Yes, if List is an Interface then List::Clone() must be pure virtual function, and every derived class should implement it.

In my understanding for dynamic memory allocation, the ownership depends on the scope of use of pointed objects. In call stack the outer most function using dynamic objets should manage them or some kind of own garbage collector/manager class can be used to handle deallocation on top of everything.

Pros please correct me if I'm wrong or missing something.