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.
If your C++ programs have resource leaks then I would suggest they were
not designed and implemented by very good C++ programmers.
If I were to compose a list of criticisms of C++ resource leaks wouldn't
be on it.
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.
LOL. You mean like web browsers, data bases, device drivers, JavaScript
engines, Java JVM's, back-end systems of Facebook, Google etc, etc.
Here's a curated list http://www.stroustrup.com/applications.html.
I would agree that C++ is a complex language and much harder to learn
than something like Java. But you certainly don't need genius level
engineers to support it.
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.
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 :-)
This is not an environment where I would like to work ... with C there
are no such problems.
And C has a completely different set of problems which is why I prefer
to use C++. And my code doesn't have any resource leaks because I stick
to tried and tested design patterns.
My 2 cents ...
Kind regards
Bernd
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
