On 13/01/2018 4:53 PM, Bernd Oppolzer wrote:
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.
I'm interested to know what the subtle bugs were. I haven't experienced
any compiler bugs in destructors in the 15 years I've been coding C++ on
z/OS.
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 ...
I prefer implicit destruction of resources. It takes careful programming
in C to handle errors and free resources that usually requires lots of
code. I've always found the best way
to do that in C is a goto that branches to a cleanup block but oddly
that seems to be banned by most company coding standards. I've been
coding Java for the last couple of years and even with GC it's easy to
leak resources especially if you store objects in collections.
C++ destructors are executed when an object goes out of scope, which is
basically when it hits a closing brace. Taking John's example of a C ENQ
function we could easily implement that in C++ so the destructor issues
the DEQ when it goes out of scope. It will always happen even if an
exception is thrown.
{
zos::scoped_enq_lock lock(major, minor);
-- lots of code ...
...
} // destructor DEQ
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
