I consider C++ a much safer language than C, wrt to both string handling
and memory management. In fact, I find it difficult to fathom why anybody
would still write C code when C++ is such a superior language. Strong
typing alone is worth the effort.
Memory leaks in C++ code are almost always due to a bad design. The RAII
idiom is widely accepted as standard practice these days - resources
are allocated in the constructor and destroyed in the destructor. This
also makes them exception safe. C++ also has proxy based garbage collection
in the form of smart pointers
http://en.wikipedia.org/wiki/Smart_pointer#C.2B.2B_smart_pointers. There
is a space and time trade-off but it's certainly worth it.
Debugging memory leaks in LE is trivial with the HEAPCHK runtime option.
It will produce a CEEDUMP when the program terminates with a trace
of all memory allocations that have not been freed, with function name,
offset, module name, storage address and length etc.
On 6/09/2012 5:34 AM, Bernd Oppolzer wrote:
I got answers like this, before.
These things work well, if you are in a development environment
or in an earlier test stage.
What we have: we have a production system or an "almost" production
system
in a very late stage. Then, when combining severel hundred PL/1
modules and
DLLs and several hundred C++ and C DLLs (written by several hundred
different
people), we suddenly discover that our service regions start to
request more
and more storage during the day shift ...
Ok, while writing this, I see the point ... our legacy C modules are
well tested,
because we have tools that support testing of components, and those tools
even check for storage leaks etc. And for the C++ components in the
new system,
we don't have such support - it's not our fault; management believed
that such
tools are not needed and only recently (after 5 years) spended some
money to
improve the development and testing process. So the C++ components are
not well tested and the problems arise in a very late stage ...
another part of the problem is that there is not enough time to do
component
tests and that many of the co-workers are not accustomed to do this -
they throw the whole thing together and start testing it as a whole -
which will not work, if you have such a large system.
The storage leak is only one small part of the problem ...
C++ as another player in this context makes things worse, not better.
When we have to examine the behaviour of the overall system, the effects
of the C++ runtime is sometimes like a mystery for us.
Very interesting effects can also occur, if a PL/1 ON ERROR unit tries
to continue on short-on-storage-conditions, which occur in C or C++
modules ...
especially if this error-handler decides to provide only minimal dump
information ...
with some 100 modules in your address space, it will take you days to
find
the error ...
Kind regards
Bernd
Am 05.09.2012 19:47, schrieb Charles Mills:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
