Masterlist, everything on heap?

[gipsy boy]

Sorry I had no idea how to name my subject.
Is this good practise? :

Suppose I have a situation that's a bit like a relational database. I
have a list of objects A, a list of objects B, and I need to have a list
of objects C. But each object C has a list of a subset of the existing A
objects and a list of a subset of the existing B objects.

Most of the students I saw do this by making all the objects on the
stack (with 'new') and putting their pointers in lists, and of course
using those pointers in the construction of C objects..

But I thought, from reading "Thinking in C++ vol. 2" that this approach
was better? :

the main program does {
list<A> objectsA;
list<B> objectsB;
list<C> objectsC;
}

where

class C {
list<A*> objectsAptr;
list<B*> objectsBptr;
}

Of course, assuming I do all of this in the right order (first creating
the set of A's and B's, inserting them into the lists, and then using
the pointers from the elements in those lists to create C objects) and
ensuring that the entries in the C lists disappear when their
corresponding objects do.

But, this way I never have to deconstruct any objects manually, right?

But is there a hole somewhere in my reasoning? Assuming I'd have to be
able to delete A,B, and C objects from main_program and also
insert/change them.

thanks for any insight,

 

[Victor Bazarov]

Sorry I had no idea how to name my subject.
Is this good practise? :

Suppose I have a situation that's a bit like a relational database. I
have a list of objects A, a list of objects B, and I need to have a list
of objects C. But each object C has a list of a subset of the existing A
objects and a list of a subset of the existing B objects.

Most of the students I saw do this by making all the objects on the
stack (with 'new')

If an object is "made with 'new'", it's in free store, not stack.

and putting their pointers in lists, and of course
using those pointers in the construction of C objects..

But I thought, from reading "Thinking in C++ vol. 2" that this approach
was better? :

the main program does {
list<A> objectsA;
list<B> objectsB;
list<C> objectsC;
}

where

class C {
list<A*> objectsAptr;
list<B*> objectsBptr;
}

Of course, assuming I do all of this in the right order (first creating
the set of A's and B's, inserting them into the lists, and then using
the pointers from the elements in those lists to create C objects) and
ensuring that the entries in the C lists disappear when their
corresponding objects do.

Yes, assuming...

But, this way I never have to deconstruct any objects manually, right?

If the pointers you store are those _to_ elements of the corresponding
lists, then the lists will destroy their own elements. So, right, you
will not have to.

But is there a hole somewhere in my reasoning? Assuming I'd have to be
able to delete A,B, and C objects from main_program and also
insert/change them.

You will discover any holes in your approach as you are implementing it.
So, go right ahead and take a stab at it.

V