Am 13.01.2018 um 07:28 schrieb David Crayford:
On 13/01/2018 4:10 AM, Bernd Oppolzer wrote:
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++.
I would respectfully disagree with that statement. C++ gained a
reputation for leaking resources in the early 90s when exceptions were
introduced. That was before the STL and everybody was allocating
string buffers on the heap. RAII solved that problem decades ago.
Because C does not support RAII semantics having to explicitly free
resources makes it much more prone to resources leaks.
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++ ...
I've lost count of how many times I've seen C code with unchecked
mallocs. Also the lack of exceptions in C makes error handling ugly
and error prone.
I consider the use of malloc/free or new/delete to be anti-patterns.
Any heap allocation should be wrapped in a smart pointer using
factory functions like std::make_unique or std::make_shared. z/OS C++
does not support those C++11 features yet but you can implement
something similar yourself or go and get boost. For char buffers use
std::vector<char> or std::string. Of course, you should always strive
for stack based instantiations.
If I see the new operator used in C++ code without something like
std::shared_ptr<Object>(new Object) it's a bad code smell. In fact I'm
leery when I see any
raw pointers in C++ code full stop. The only pointers I use are smart
ones.
The problems we had in C++ had not to do with the explicit use of
new or malloc and forgotten frees etc.; they were much more subtle
and hard to find. There were errors in some class definitions, leading to
memory leaks, because the destructors of the class didn't work properly.
As I told you, even the very experienced C++ guys at the site claimed for
a long time that all was correct and there are no memory leaks in their code
until I proved it using - for example - CEL4MCHK. And then, days later, they
told me: oh, well, now we found it. And that was not one time, but many
times. You could say on every release of the software package. We did not
have such issues with the C part of the software, because there every
malloc / free is explicit and VISIBLE ...
We never needed tools to make our C software memory safe ... discipline
on the coders' part (never leave a function before freeing all the memory
you malloced) was sufficient for more than 20 years.
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
