Re: Exception Misconceptions
On 19 Dec, 21:39, "Balog Pal" <p...@lib.hu> wrote:
[concerning memory leaks...]
And I NEVER EVER saw the issue of this kind with Java.
I never had problems with memory leaks in C++. (not like with
Interesting. I can't remember ever having had any problems with
memory leaks in C. I do remember one in C++, recently. Due to
a compiler error resulting in the compiler not calling a
destructor. (But it wasn't in code I'd written. Had the code
been slightly cleaner, it wouldn't have triggered the compiler
error. But VC++ has problems with getting the destructor calls
right if you return in the middle of a loop.) But most of the
leaks I've seen have been in Java. Not because of the language,
but because of people trying to get the code out the door too
quickly, making the classic error of skipping on the design,
because "that's not what we're delivering".
The secret, of course, is good up front design. It's true that
it requires more work to avoid all leaks in C than it does in
C++, and (slightly) more work in C++ than in Java, but if you're
organization doesn't do good up front design (and design and
code reviews, and unit tests, and all the rest), you will have
problems (and Java won't solve them), and if it does, then you
won't have memory leaks. The advantage of things like garbage
collection isn't that they solve problems you wouldn't solve
otherwise---they don't. The only advantage is that they reduce
the total amount of work necessary in the solution.
Many people here have the same experience. Yes, writing
programs including smilar to that you described. Just use a
manager, like a smaprt pointer consistently with every
allocation. No leaks possible.
And that's the kind of comment which gives C++ a bad name.
There are no silver bullets, and in well designed code, you
typically don't have that many smart pointers. (Although I'm
pretty sure it depends on the application domain---there are
probably domains where boost::shared_ptr solves 90% of your
memory management problems. I've certainly not worked in such a
(And if you need to keep blocks unreleased an indefinite time
waiting user interaction -- that is not a leak issue, but
consequence of a general design decision.)
The classical case of a leak is when you "register" a session in
a map, mapping it's id to the session object, and forget to
deregister when the session ends. At least, something along
those lines accounts for most of the leaks I've seen.
One heavy duty program I wrote in Java works like a champ
for years without a SINGLE issue with memory leak and gc is
so efficient that it is not far from automatic stack
Note that this is very application dependent. Actual allocation
with a copying collector is about the same as alloca in terms of
performance, and if you can arrange for all of the runs of the
garbage collector to be in otherwise dead time, you'll likely
significantly outperform a system using manual allocation. But
there are a couple of if's in there---for most applications I've
seen, the performance difference between garbage collection and
manual allocation won't be significant, and there are
applications where garbage collection is significantly slower,
or simply can't be used.
Cool. And *all* I signed off for deployment work the same,
and wrt not only memory but files, locks, and any other stuff
that requires cleanup. In C++. Using the same, quite trivial
I'll repeat: there's no silver bullet. And I've yet to see a
smart pointer which solved all of the memory management issues
without significant additional work.
Take for example the issue with writing a portable GUI code.
Is there such a thing?
For any reasonable definition of "portable". (No GUI code can
be made to work on an embedded system without a terminal, for
example.) One of the advantages of Java is that Swing is
actually fairly well designed. From what little I've seen of
the C++ GUI libraries (where unlike Java, you do have a choice),
they weren't as well designed. But they're likely sufficient
for a lot of applications---I know that I use GUI applications
(e.g. Firefox) which are written in C or C++, and they more or