How would you do this (object interlinking)

I have a parent object and quite a lot of child objects (that are not fields of the parent).
The parent doesn't rely 100% on them, but it sometimes needs their support.
Sometimes a child object needs help by another child object.
Therefore the parent object needs to know all child objects, each child object needs to know (almost) every other child object but none of them needs to know the parental object.

Until that point, normal pointers do the job quite well. However, sometimes child objects die (the parent is immortal) and need to be replaced. In that case I would have to copy their new pointer target to all the other child objects which is possible but probably not very clever style.

So I thought about using references in the child objects. The parent still keeps pointers to valid child objects and each child object keeps a reference of the pointers of interest for it. So updating a pointer in the parent object would at the same time update all of the child objects.
Unfortunatly, I can't use references in objects because they need to be initialized and thats not possible in a class (or am I wrong?).

Is there any other way without the use of a pointer to a pointer (which would result in pretty messy code) ? Or maybe a trick to use references ? Should I use a different concept (ouch) ?

Are these the same *types* of objects, or are the child objects derived from the parent. Would you mind giving a code example of your problem?

One of the most common approaches actually uses a feature you thought unnecessary: To have the children simply retain a pointer to the parent. This actually solves the data integrity issue quite well. Here's an example:

I'm not sure about how I could give a code example that is not too long.

The objects maintained by the engine(parent) are of rather different nature: a renderer, a windows message handler, a macro association engine that resolves function name-strings to C++-function pointers, an array of BSPs, a camera.... etc... so all kinds of different stuff. Some of them require support by others, i.e. the camera needs access to the renderers modelview matrix.

I thought about what you said: Giving all child-objects a pointer to the parent object. That might work, but wouldn't it require all of them to include the header of the engine class? How could I do this if at the same time the engine requires headers of all of those classes.

Hmm, I think you have way too much interdependancy on your part. Try using some version of the Controller-Model-View scheme. There are a number of variations of this, I prefer my own, which I call ICMV (Interface - Controller - Model - View). I have four main classes, which form a single "item":

Interface : This is the main class; to construct the item, you construct this class. It exposes different functions, but internally it just forwards all function calls to Controller. The reason that I make this class, not Controller, the main class is because I want to be able to swap Controllers and use them polymorphically.

Interface has, as private data members, a pointer to Controller, and an instance of Model.

Controller: A base class from which all controllers of this type are derived. The controller is the brains -- all input goes here, and it makes all the choices about what to do.

Controller has, as a private data member, a reference to Model.

Model: This class encapsulates the state of the item. Most of the item's variables are stored here. The state is updated by the Controller and read by the Views. Model is also responsible for owning Views.

View: This is an ABC, its child classes implement ways of looking at the model. Graphics, sound, disk, etc. outputs. It has a reference to Model, but in general, Views should never modify Model (I usually make it a reference to const).

Essentially, the Controller is the brains of the item, making all the decisions as to what to do next. The Model is the state of the item, which should contain all information about the item itself. The Views are ways of representing and displaying the data of the Model.

The Controller makes choices and updates the Model. It also tells the Views about the changes, and the Views decide if they have to do anything as a result. Interface just wraps everything up and allows polymorphism from Controller.

Thanks for your help. I just had an idea how I could resolve all those dependencies.

CEngine (parent) does not use any membersfunctions of it's child objects in the public scope. So I used a PIMPL to hide the private scope and forward declared all child objects. The engines public scope only requires pointers to child objects (in the various registerXXX(xxx_type*) functions), so I don't need to include their header anymore.

Thanks for your help, I got the idea while trying to write down the symbolic description of the classes inter-relationship you suggested!

edit: I just read you post Cat. I'm not sure if I understand your basic concept at all. You use some kind of "hub" that forwards all the information between the objects. Is that right? That sounds great, but also like a lot of overhead (to type). I guess I'll print that and try to grasp it