How can I make an object know what container it is in?

Question

I need a way to put various items into sets. Each item can be in only 1 set at a time. I also need to be able to ask the item which set it is in. I have 3 questions:

Is this a valid implementation?

How can I use this if I split the classes into multiple header files, because each class requires the other?

Can I use a reference instead of the pointer to Manager in item class (because I don't like pointers)?

class Manager {
public:
  add_item(Item& item) {
    items.insert(&item);
    item.manager = this;
  }
  remove_item(Item& item) {
    items.erase(&item);
    item.manager = nullptr;
  }
private:
  std::unordered_set<Item*> items;
}

class Item {
public:
  Manager* get_manager() {return manager;}
private:
Manager* manager;
}

Answer 1

Is this a valid implementation? How can I use this if I split the classes into multiple header files, because each class requires the other?

You should use forward declarations.

In a good Object Oriented Design your object should not know how it is stored. It looks like your object should not be responsible for the activity which needs to localize the object.

std::unordered_list<Item*> items; 

This is not proper. Do You want to hash addresses of the objects?

Can I use a reference instead of the pointer to Manager in item class (because I don't like pointers)?

When passing to the function You can always replace pointers with references. There is no problem with it.

Answer 2

How can I make an object know what container it is in?

You should not need to do so ever in a proper class design. There are things like Dependency Injection, but I think that's beyond your actual needs.

Is this a valid implementation?

No

How can I use this if I split the classes into multiple header files, because each class requires the other?

Use forward declarations (have a look here for more details).

Can I use a reference instead of the pointer to Manager in item class (because I don't like pointers)?

No, you cannot.

---

More in depth beyond your actually asked questions, it seems to be a design issue in the end, and you're asking for XY problems.

That you don't like (raw) pointers is a very good guts feeling, what might be wrong with your actual design. Well, unfortunately you can't manage references using standard containers like std::unordered_set.

What you can do though, is using smart pointers as provided from the Dynamic memory management facilities.

Primary decision you have to take is, which of the various smart pointers like std::shared_pointer, std::weak_ptr or std::unique_ptr is the right one to manage your necessary ownership requirements semantically correct.

Also Manager might not be the best naming choice for what you want to do. Lookup the classic Design Patterns please, if there's something fitting better from these.

For example, it sounds you need something like an Observer, that tracks a number of Item changes/events, and forwards these to other registered Item instances.

Because Observer doesn't need to have ownership for any of the registered Item instances, a std::weak_ptr seems to be the right choice to reference any of them.

Answer 3

I need a way to put various items into sets. Each item can be in only 1 set at a time. I also need to be able to ask the item which set it is in. I have 3 questions:

Is this a valid implementation?

The basic ideas are sound, though it doesn't enforce your data model or defend against problematic scenarios. For an example of what you could do:

void add_item(Item& item) {
    if (item.manager == this) return; // already owner
    if (item.manager) // already has another owner...
        item.manager->remove(item);
    items.insert(&item);
    item.manager = this;
}

How can I use this if I split the classes into multiple header files, because each class requires the other?

Why would you want to? The classes seem too simple for there to be any need, and it just complicates things. (The proper way to do it is with forward declaration headers.)

Can I use a reference instead of the pointer to Manager in item class (because I don't like pointers)?

Not with your current design, because your code sets item.Manager to nullptr after removing an Item from a Manager, which is a reasonable thing to do.

More generally, you do need to ensure the actual Item objects' lifetimes span the time you're storing pointers to them in the Manager objects. That may or may not be a natural consequence of the way your code's written, or easily achieved by calling item.manager->remove(item); before the Item's destruction.

Answer 4

Assuming Manager is not expected to own the Items and you have a clear idea of the lifetimes of both the Items and the Manager then this seems reasonable.

If you want to split the classes into separate header files Item.h just needs a forward declaration of Manager. In fact, as it stands, Item doesn't need a complete definition of Manager at all so you could structure it as simply as:

Item.h

class Manager;  // forward declaration

class Item {
public:
  Manager* get_manager() const { return manager; }
  void set_manager(Manager* new_manager) { manager = new_manager; }
private:
  Manager* manager = nullptr;  // Ensure initialized to null
};

Manager.h

#include "Item.h"
#include <unordered_set>

class Manager {
public:
  void add_item(Item& item) {
    if (item.get_manager())
      return;  // Item can have only one Manager
    items.insert(&item);
    item.set_manager(this);
  }
  void remove_item(Item& item) {
    items.erase(&item);
    item.set_manager(nullptr);
  }
private:
  std::unordered_set<Item*> items;
};

Live demo.

As for not liking pointers, if you want a non-owning reference that could be null then a pointer is a pretty good fit. Pointers are generally more suitable than references for member variables because references restrict what you can do with the class considerably.