So B and C just need a reference (possibly const, depending on whether they will modify the A)
Aren't storing references a bad idea? http://stackoverflow.com/questions/892133/should-i-prefer-pointers-or-references-in-member-data . Again I'm only going by what I'm reading online.
Let's examine the objections in the accepted answer:
you are forced to initialise the reference in each constructor's initialiser list: there's no way to factor out this initialisation into another function (until C++0x, anyway)
First, the initialiser list is the correct place to initialise member variables. Second, it's 2015 and almost every major compiler has support for delegating constructors.
Besides, even if you can't use delegating constructors, it's not a massive maintenance burden to initialise your reference.
the reference cannot be rebound or be null. This can be an advantage, but if the code ever needs changing to allow rebinding or for the member to be null, all uses of the member need to change
If the object you are referring to cannot be null, then this is a good thing. If it can be null, then you shouldn't use a reference. In your case, your B class expects an A object to exist for the lifetime of the class.
unlike pointer members, references can't easily be replaced by smart pointers or iterators as refactoring might require
Again, you are expressing your intent through the language features. A reference implicitly tells you that the B class expects an A object to exist for the lifetime of the B object. If you change that intent, you should change the code to reflect that. Changing from a reference to a pointer will cause your code to fail to compile. That is A Good Thingtm. The compiler is now helping you see where your reference/pointer is used and forcing you to examine the usage of it in each context.
Horses for courses.
If the injected object can be NULL: use a pointer.
If the injected object can be swapped out for a different object: use a pointer
If the injected object is not clearly owned by anyone: use a shared_ptr to create it and a weak_ptr to reference it.
But...if in the case like this where the injected object cannot be null and must exist for the lifetime of the client object: use a reference.
Note that it's perfectly legitimate to store a raw pointer here to represent the concept of "NO ownership."
I like this approach, even though raw pointers are usually not good. I think if someone was to read my code and saw it, it would clearly convey there is no Ownership of this b2World object. If I take this approach, it would mean that I don't need to delete my a object in the destructor of both B and C. It would need to be handled separately? Something like this then:
main(){
A aObject;
B bObject(&aObject);
C cObject(&aObject);
}
Then A would be deleted when it goes out of scope along with B and C automatically.
Note that that approach will work equally well with references.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
