Memory Leak Issue

[Lykurg]

My requirement is to have,
N different arrays capable to hold at-most 50 items, for each key.

That's not enough information to decide. If you insert an item. Where will you insert? Always at the end/front. In the middle? And when you want access an item. Where is that item? Front/back/middle? Different, or always the same location?

[linuxdev]

Sorry for not providing the information at first.


Here is complete detail:

a. The data is received from network at continuos intervals
b. The data has an unique Id/key associated with it.
c. For each key i receive, next data/update in a interval of 3secs.
d. I need to store a maximum of 50 updates for each data, and many such data and the data is always stored sequentially.
e. i just access these data only sequentially.
f. There can be atmost 200 such unique data in my application at any point of time.
g. i need to do an efficient search based on the Unique ID.

If you need more information, i am working on Radar Display Software, and data called Track data (Detections) is recevied from radar at specific intervals, say 3secs.

Each Track has an ID/Key associated with it and there can be atmost 200 Tracks and any point of time in the application and hence in my display and database.

for each Track, i need to store trial information, this is nothing but the history for a particular track. This data is just stored sequentially.

My current design is,
I have an QHash, which has TrackId as key and pointer to QVector as Value.
Each time i receive a new track, i create a new QVector and append the new track data as the first element and on every update i just append to the end.

When a data for already existing key is received, i just append to the end of QVector which already exists.

You can get more information from the function, "track+dbase" i have posted earlier.

Hope you find this useful...

[Lykurg]

Ok, QHash is the best for providing fast lookups and if you don't need the maximum 200 items to be ordered, perfect.

The point with QVector is, that it stores all items in adjacent positions in memory. So to avoid much coping use QVector::reserve(). But then you need a "lot" of space. Don't know how much is available (embedded?). If I haven't make a mistake while counting 200 keys with 50 items is only about 5 MB of disk space, so I think you can keep your QVector.
But if you store pointers to the items TTrack, then I would take a QList.

QHash<int, QList<TTrack*> > foo; //first choise
QHash<int, QVector<TTrack> > bar; //second choise

QHash<int, QList<TTrack*> > foo; //first choise
QHash<int, QVector<TTrack> > bar; //second choise

To copy to clipboard, switch view to plain text mode 

And if you need to store pointers to the vector, don't forget delete on it when removing a key from QHash...

[linuxdev]

Thanks i have taken second choice ...