Analyzing the current source code, looking for all the uses of new operators currently used, here's what was found:
Tokens – allocated in a number of places; these have been where most of the memory leaks have been found
Strings – for now these are allocated when creating tokens, so if the tokens get deleted these will get deleted (in the Token destructor)
Stacks – the arrays in the stacks upon first creation and when expanded; the arrays will be deleted when the stacks go out of scope (as part of the destructors of the classes that use them)
Lists – the elements of the list, which are deleted when the lists go out of scope (as part of the destructors of the classes that use them)
Translator Output list – this is a one time allocation in the Translator when a new translation is initiated; it is handed over to the caller when getting the translated results; so it's up to the caller to clean this up (currently handled in the test code)
RpnItems – everyone of these that are allocated is appended to the Translator's output list, so these will be handled when this list is cleaned up
Table – one time allocation in the main function, which is not important as there is only one, but a delete was added at the end of the main function
Error Lists – these are allocated as part of the Token and Table initialization when an error is detected, but were never deleted, which is not important as these were only created when there was an error (and the program exits), but deletes were addedSo it looks like Tokens are the only specific area where there is currently a problem with memory leaks. Next, a simple solution for detecting token leaks...
No comments:
Post a Comment
All comments and feedback welcomed, whether positive or negative.
(Anonymous comments are allowed, but comments with URL links or unrelated comments will be removed.)