In many C++ implementations it is possible to replace 'new' with your own 'debug_new' via a macro, and trace or link all of the "malloc's.".
Both of the C++ environments that I use (IBM z/OS XLC and MS VS) have built-in "find the leak" functions that I use routinely to make certain I am not leaking storage. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Wednesday, September 05, 2012 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings I agree that string handling with "normal" C string functions is problematic and error-prone; here the Pascal heritage (where "strings" are also arrays of chars) seems to be a problem. But I recently had so much problems with C++ strings, that I don't believe that this is really a solution. The problem was that there were some C++ classes which allocated string objects but didn't free them. So over time the whole heap storage got used up, and we had no - easy - chance to find the culprit, given several hundreds of modules (or DLLs) with C++ code. In the old (legacy) system, where only C was allowed, we did all storage allocation through a site specific malloc replacement, so we were able in a similar situation to trace all storage allocations, and more: we registered all storage allocations in a linked list (in fact it's a tree structure), and this way, at a certain point in the application logic, we could implement a function that frees ALL remaining storage. So in the legacy system we never had such problems that we now have in the C++ system, and we have no chance to implement a similar "safety belt for storage allocations" in the C++ system, due to the peculiarities of the C++ storage management scheme. So the comfortable C++ runtime features in fact makes it impossible for us to implement safe schemes of storage management like we had them before. C++ is part of the new system mainly because one person suggested it; the architects of the "old" system advocated against it, but management decided not to follow them. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
