SRL Archive - Help and Support

- It's a HW assignment, so knowledge over solution if possible
- It's a HW assignment, so I'd still love the solution(s)
- Problem: initializing objects from file, leaking memory
- linux/valgrind reports leaked memory

files zipped below[ATTACH]23362[/ATTACH]

also heres a junky uml knockoff diagram

[ATTACH=CONFIG]23363[/ATTACH]

Lets trace the code from your driver..

int main() {
    firm theLOSEFirm;
    theLOSEFirm.startUpDay();
    theLOSEFirm.displayEndOfDay();
}

Firm is allocated on the stack. Good.
startUpDate does quite a couple things on the heap. The first is allocated a BST and inserting into it via: initializeClientele.
Upon destruction, the BST clears all nodes. Good.

Next it does: initializeTransactions and also inserts into the same BST. Upon destruction, everything is deleted fine.
Good.

Now it calls: clients.performMultipleTransactions(). Which calls: performTransactions(*transactionLineUp); Which then calls: bool clientele::performTransaction(const transaction & singleTransaction)

in a loop.

Lets examine this.. sourceClient is allocated on the heap and deleted in every branch statement as well as at the very end. Good.

destinationClient is allocated on the heap and deleted in every branch statement as well as at the very end of its only branch. Good.


Now we get to the issue. transaction * transactionToAdd = new transaction(singleTransaction); is allocated on the heap. A copy of it is stored using void client::logTransaction(const transaction & theObj) which calls: clientsHistory.addToLog also making another copy. It calls: historyLog.push_back(history(toAddToLog)) making a third copy due to its constructor: history::history(const transaction target). push_back did not make a copy if using C++11 because it'd do a move construction/inplace construction there. The copies are due to the functions called.. Lets ignore that as its not the issue at the moment..


However: transaction * transactionToAdd = new transaction(singleTransaction) is an issue as it's never deleted anywhere. It goes out of scope and voila.. Leak.

This is done in every branch statement.. Assume it is called 11 times, you now have 11 leaks and 33 copies of the same object. The compiler can optimise out the copies in some (most cases) but you'd still have 11 leaks.

All in all, your leak is in: bool clientele::performTransaction(const transaction & singleTransaction)

Cheers man, very thankful for your input.

What you said helped me clean up the mess and I've now no memory issues (as in accord to linux/valgrind).

If I remember, I'll post the final code after the quarter finishes, just for the learning aspect for onlookers.

(Also funny I still cannot add to your rep. @Brandon; until I spread more rep. elsewhere first)

me then him :)? lol jks, long time havent seen u here.