Question

I have this application that requires me to have a QList which will contain 1 < x < 10000+ objects. Now I have a few issues.

First of all, should I declare the QList as a pointer or straight on the stack? The objects in the QList are pretty small and are wrappers for QFileInfo. But how should I do this?

1. A list of objects on the stack?
2. A list (on stack) of pointers to objects on the heap?

3. A..

     QList<FileInfoWrapper>*
   

Firstly, if I picked solution 2, would my heap be a mess since I just allocate small portions of data all over the place? I dont want that.
Secondly, if I pick the 3rd solution, how would this look in memory when I access the individual objects? And could I create pointers to them (they are afterall on the heap)?

Then we come to my other issue. This list will be past around like a fork at a diner and at some point I would like to create sublists that doesn’t hold any data, only references/pointers to some of the objects in the list(for example object 0 to 250). I will then throw these lists into different threads that will have to have a ref to the object to be able to edit them (read: not a hard copy).

Also, could someone explain exactly what happens on the heap when you create a list like this:

QList<FileInfoWrapper>* list = new QList<FileInfoWrapper>();

Would it be like in c where you just create a pointer to the offset where that object will be located?

*(list + sizeof(FileInfoWrapper) * 10)

Answer 1

QList is a container class … that means that it manages the memory for you so you don’t have to worry about it. It’s underlying data-structure is a variant of a deque with some special modifications, so your understanding of indexing into the list is not correct. But either way, these are details that are abstracted away by the interface, and you don’t need to worry about them. You simply use the given class methods like operator[] or at() to obtain a reference to an object at a given index, and other functions like push_back() or insert() to copy objects into the container. So you can simply make a QList instance on the stack (as long as it doesn’t go out-of-scope while it’s needed), and copy objects into it. The underlying data-structure will properly allocate the memory needed dynamically to store the objects, and at the time of destruction of the QList object, it will deallocate the memory used to store the objects it “owns”.

Think about QList as you would think of a STL container like std::vector or std::list … again, the underlying data-structure for QList is not the same as these STL containers, but the point is that you can allocate the data-structure on the stack like you would any other class, and it contains all the private data-members and information necessary to manage the memory on the heap. Allocating the QList on the heap through a call to new doesn’t gain you anything in that regard … there are already pointers, etc. inside the data-structure allocating and managing the memory of the contained objects for you.

Finally, don’t worry about data-fragmentation. The point of a good container class is to properly allocate memory to avoid memory fragmentation issues from allocating and reallocating memory too often. Additionally, allocating memory takes time, so if a container class were to constantly need to call new, that would really hurt it’s performance. While allocating memory on every insertion may be a necessity for node-based containers like linked-lists and trees, hash-tables, dynamic-arrays, and other block-type data-structures are much more efficient at utilizing the memory they allocate to minimize these allocation calls.