Title: C++ Is making objects depend on others a good design?
Tags: c++;oop
Question: I have a basic design that consists of three classes : A Data class, A Holder class wich holds and manages multiple Data objects, and a Wrapper returned by the Holder wich contains a reference to a Data object.

The problem is that Wrapper must not outlive Holder, or it will contain a dangling reference, as Holder is responsible for deleting the Data objects. But as Wrapper is intended to have a very short lifetime (get it in a function, make some computation on its data, and let it go out of scope), this should not be a problem, but i'm not sure this is a good design.

Here are some solutions i thought about:
-Rely on the user reading the documentation, technically the same thing happens with STL iterators
-Using shared_ptr to make sure the data lasts long enought, but it feels like overkill
-Make Wrapper verify its Holder still exists each time you use it
-Any idea?

(I hope everyone can understand this, as english is not my native language)

Edit : If you want to have a less theoric approach, this all comes from a little algorithm i'm trying to write to solve Sudokus, the Holder is the grid, the Data is the content of each box (either a result or a temporary supposition), and the Wrapper is a Box class wich contains a reference to the Data, plus additional information like row and column.
I did not originally said it because i want to know what to do in a more general situation.

Comment: Probably the first *and* third option. At least, provide a means to check if the wrapper is "valid". As for the shared_ptr, it isn't so much that it is overkill, but it changes the semantics. The holder no longer is the owner of the objects, and no longer controls their lifetime. So it depends on whether this matches your use-case or not.

Comment: "feels like overkill" why is that?

Here is the accepted answer: Only ever returning a ```Wrapper``` by value will help ensure the caller doesn't hold onto it beyond the calling scope.  In conjunction with a comment or documentation that "Wrappers are only valid for the lifetime of the Holder that created them" should be enough.  

Either that or you decide that ownership of a ```Data``` is transferred to the ```Wrapper``` when the ```Wrapper``` is created, and the ```Data``` is destroyed along with the ```Wrapper``` - but what if you want a to destroy a ```Wrapper``` without deleting the ```Data```?  You'd need a method to optionally relinquish ownership of the ```Data``` back to the ```Holder```.

Whichever you choose, you need to decide what owns (ie: is responsible for the lifetime of) ```Data``` and when - once you've done that you can, if you want, use smart pointers to help with that management - but they won't make the design decision for you, and you can't simply say "oh I'll use smart pointers instead of thinking about it".

Remember, if you can't manage heap memory without smart pointers - you've got no business managing heap memory with them either!

Comment for this answer: In my design i decided that `Holder` would be the class that manages `Data` lifetime, as it makes no sense to make `Wrapper` responsible for this : compare with `st181a:6c1c:918f:f3a4:2e8c:61d6:1a08:6b16vector` and its iterator : `vector` is the `Holder` and iterator is the `Wrapper`. By the way, i'd prefer not to use smart pointers because they force me to use heap memory whereas i could do everything on stack in my situation. But, as i am not making a STL container, would it be recommended to use the same design strategy? ("If you do that it's UB")
Comment for this answer: One of the first tidbits in the book Effective c++ is "Always favour the stack", so yes anywhere you can avoid heap allocation, do so.  I'd also say that generally if you want to pass an 'alias' to an object on the stack then use a reference *not* a pointer.  This means that it's impossible (almost!) to inadvertently try to delete the object.

Here is another answer: To elaborate on what you have already listed as options,


As you suggested, ```shared_ptr<Data&gt;``` is a good option. Unless performance is an issue, you should use it.
Never hold a pointer to ```Data``` in ```Wrapper```. Store a handle that can be used to get a pointer to the appropriate ```Data``` object. Before ```Data``` is accessed through ```Wrapper```, get a pointer the ```Data``` object. If the pointer is not valid, throw an ```exception```. If the pointer is valid, proceed along the happy path.



{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 2, 'CommentCount': 2, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2015:00:07/29/15', 'FavoriteCount': 1.0, 'PostTypeId': 1, 'Tags': '<c++><oop>', 'Title': 'C++ Is making objects depend on others a good design?', 'ViewCount': 129, 'id': 31704188, 'user_AboutMe': None, 'user_AccountId': 6704393.0, 'user_DisplayName': 'Alexandre S.', 'user_Reputation': 127.0, 'user_Views': 4.0, 'user_id': 5169896.0}}