> memory leaks are omnipresent with C++ I disagree. I will wager there are *zero* memory leaks in my code, other than a couple of disaster startup errors where I intentionally bail out prematurely.
I do my alpha development on MS Visual Studio. If I run a test and there are any memory leaks, it tells me. It shows me the length and 8 or so bytes in hex and character. If that is not enough to find the leak, it also assigns every malloc a number, and shows the offending malloc number. I can breakpoint on that malloc number and find the offending allocation. As part of our regression testing I run with HEAPCHK and that tells me if I have any leaks on z/OS. More to the point is just discipline. Whenever I write a new (C++ for malloc() or 'GETMAIN') I stop and think "where will this get deleted" and code the delete right then and there. This is something that could be done trivially in code review. > With C, for example, you can always catch the storage allocations functions > ... > and replace them in the whole software package by something different > which does all sort of diagnose, all that you want. Try that in C++ ... Trivial. new is an operator. You can override it just like any other operator in C++. https://www.geeksforgeeks.org/overloading-new-delete-operator-c/ Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Friday, January 12, 2018 12:10 PM To: [email protected] Subject: Re: curious: Popularity & use of C on z/OS. Am 12.01.2018 um 20:42 schrieb Seymour J Metz: > I disagree; C is not remotely like assembly language, and the pre-processor > is pathetic compared to any other macro facility that I have seen. The > confusion between pointers and arrays and the zero-delimited strings are > booby traps for the unwary. > > As to C++, it provides classes that are not subject to all of the pitfalls of > the underlying C, so I would regard it as a safer choice. My experience is: C++ is VERY unsafe, because memory leaks are omnipresent with C++. Even very experienced C++ developers (in their own thinking) have a very hard time explaining what's the reason of the memory leaks that I discovered in their code. To make it clear: I am a C programmer (and PL/1, ASSEMBLER, Pascal etc.) and don't think of myself as a C++ expert; I only wrote some entry level C++ programs. But I was in charge of the maintenance of a very large software system which had SOME C++ modules in it; the greater part was C. And the memory leaks almost always occured in the C++ part. I used some tools like the MEMCHECK heap manager (CEL4MCHK) and other tools (even self-written) to locate the memory leaks in the very large code base; the C++ folks tried the same with ValGrind, but most of the time I was faster. IMO, C++ cannot be used to produce large reliable software packages; you would need ONLY SUPER SMART developers in your team, but as soon as there are some mediocre co-workers, you are lost. With C, for example, you can always catch the storage allocations functions (there are only 4, after all: malloc, calloc, realloc, free) and replace them in the whole software package by something different which does all sort of diagnose, all that you want. Try that in C++ ... Furthermore, when fighting with those memory leaks, I discovered (and my C++ affine co-workers, too), that the different implementations of C++ on the mainframe, on Windows, on Solaris, did DIFFERENT things, which were all allowed by the standard. The C++ specialists couldn't agree about which platform does it right :-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
