Class A contains class B, class B points to class A

[Joseph Turian]

Okay.

So I have a class A, which contains a vector of B.
Any B item is owned by a single, unique A. Indeed, when we create A, A
creates its B items.

B would like to know which A it is contained in, without having to be
perpetually told it by being passed A when B methods are called.
How can B store its A (or some handle to A) if A stores B?

Say that B has a pointer to its A.
However, if I create a copy of an A object and delete the original, all
the B->A pointers are invalidated. Doh!

Another solution would be to have a boost::shared_p tr to A in each B.
But that doesn't work, because when you construct an item of type A and
it wants to create the items of type B, A is a plain object and hasn't
been created using the smart_ptr 'new'.
[sorry to get slightly off-topic from vanilla C++ here]

Anybody have any suggestions?

Maybe someone can suggest an appropriate pattern or way to redesign?

Thanks

Joseph

[Greg]

Joseph Turian wrote:

Okay.

So I have a class A, which contains a vector of B.
Any B item is owned by a single, unique A. Indeed, when we create A, A
creates its B items.

B would like to know which A it is contained in, without having to be
perpetually told it by being passed A when B methods are called.
How can B store its A (or some handle to A) if A stores B?
Why specifically does B need to know which A it is contained in? In
fact, why does B need to know about A at all? If a routine retrieves a
B object through A than it will already know the A object with which a
particular B object is associated.
Say that B has a pointer to its A.
However, if I create a copy of an A object and delete the original, all
the B->A pointers are invalidated. Doh!
All the more reason for B not be burdened with knowledge of A. At any
rate the copy semantics of A have to be worked out on their own. And
the more simple the data structures involved, the better.
Another solution would be to have a boost::shared_p tr to A in each B.
But that doesn't work, because when you construct an item of type A and
it wants to create the items of type B, A is a plain object and hasn't
been created using the smart_ptr 'new'.

As long as the A object is allocated dynamically then it can be
maintained by a shared_ptr. But of course the overhead of every B
object in the vector pointing to the same A object significantly
increases memory usage and "housekeepi ng" chores - providing yet
another reason for B not to know anything about A.

The tendency when initially designing data structures is to overdo the
cross references. The thinking is usually that such links are "useful"
or "necessary. " However in practice such links rarely prove their value
and are generally used to replace more thoughtful planning or a more
well-considered design.

A better approach is to start with structures that contain no more than
the bare minimum of information (that is, with no duplicated
information). Less is more. It is always possible to add additional
fields subsequently should such information turn out to be needed.

Greg

[Joseph Turian]

Greg wrote:

Why specifically does B need to know which A it is contained in? In
fact, why does B need to know about A at all? If a routine retrieves a
B object through A than it will already know the A object with which a
particular B object is associated.

Because we a typically working with items of type B.

As you suggested, I've rethought the design.

Here's how it used to be:
A inherited from class C. C was the information shared among all the B
items.

Here's how it is now:
A creates a smart ptr to C, which the B also point to.

I think that suffices.

Thanks!

Joseph

[puzzlecracker]

hmm

[Heinz Ozwirk]

"Joseph Turian" <tu****@gmail.c om> schrieb im Newsbeitrag
news:11******** *************@g 14g2000cwa.goog legroups.com...

Okay.

So I have a class A, which contains a vector of B.
Any B item is owned by a single, unique A. Indeed, when we create A, A
creates its B items.

B would like to know which A it is contained in, without having to be
perpetually told it by being passed A when B methods are called.
How can B store its A (or some handle to A) if A stores B?

Say that B has a pointer to its A.
However, if I create a copy of an A object and delete the original, all
the B->A pointers are invalidated. Doh!

If an object knows that it is owned by another object you shouldn't delete
it without telling its owner. How would you like it, if the money you own is
spent by someone else without telling you?

Also, if an owned object is copied and the new object should also be owned,
the owner of the new object must learn about the existance of the new
object. Otherwise you must not copy the pointer (or whatever) to the owner.

If your objects are so closely related, the owning object must be notified
of all relevant changes of an owned object, and of cause the owning object
must also inform its owned objects of all relevant changes.

It might be usefull in some cases, that an owned object knows about its
owner. But even then an owned object should not implement operations, which
create or delete owned objects. You could provide some method to get the
owner of an object and then call methods of the owning object to create or
remove owned objects. You can even provide such methods for owned objects,
but such methods should only call methods of the owning objects to perform
such tasks.

HTH
Heinz

[AD]

"Say that B has a pointer to its A.
However, if I create a copy of an A object and delete the original, all
the B->A pointers are invalidated. Doh! "

I think this can be easily taken care by defining appropriate copy
constructor and assignment operator so that when a copy of A is made
then the copy gets its own copy of B and deleting original A won't
leave any dangling pointers in copy.