Re: Exception Misconceptions
"James Kanze" <james.kanze@gmail.com>
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.
I don;t see much difference between my comment and yours -- we do similar
things (proper design and match it in code) and have the same result (no
leaks).
There are no silver bullets, and in well designed code, you
typically don't have that many smart pointers.
I said "manager" that is *like* a smart pointer. string, vector, list is a
manager, and is not a smart pointer. I certainly agree that stts on a
regular program would find ust a few smart pointers compared to anything
else.
But safe coding have consistent manager usage, replacing "raw" stuff. Just
like you wrote before, that dynamic allocation is not left in a raw pointer,
but put in a smart one, and .release() it at return or transferuing to
another manager.
Even if it looks like done "immediately" with just one line between. ;-)
(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
domain, however.)
Me neither. Still I think it is a good forum reference.
(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.
Yeah, we discussed it a few weeks ago. This has nothing to do with coding
or any language -- a flaw in design/reqs that will hit in any possible
implementation.
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
deallocation.
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.
To start with the memory footprint starts as 2-3x as big. Actually did
anyone heard a reporting firewall implemented in java?
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
approach.
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.
Well, my mistake, I planned to write a summary of the last discussion to sum
up the point where misunderstanding remains -- then decided they must be
evident.
Trivial approach here applies to transfering design to code, not solution in
general. The hard part is to have an abstract design that matches/solves
the problem. That includes the flow of information, and makes clear which
pieces are needed at which point.
My experience that the work to code it in a leak-free way is piece of cake
in comparision, when the flow is complicated. And when it is
straightforward you can do it with eyes closed.
[...]
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.
Can't comment on that.
One of my current project picked java UI with Swing because it has
auto-layout. What sounds like a cool idea when you must issue the app in a
dozen languages. And you can just have a ranslation table for the UI
strings, the rest will work.
Well, in practice it wasn't all that bright, and the auto property turned to
create a big deal of issues when translated stuff had a different size...
On windows I still keep stumbling into programs that spoil the interface
just because I have "big font" setting. (using 1280x1024 res was far from
common back in '98 but I thought today lowes should be strange...)
The point is, I see examples that GUI gets spoiled even on the same
platform, using its natural features -- either having the items fixed or
auto-moving.
That keeps me generally sceptic wrt GUI portability. Without a big deal of
manual work at the QA dept and coding too...
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.
Well, at elast the libraries for windows do use the Windows UI the natural
way, and give you access to common controls. So at least can solve the
situation where the req says to work on Windows, but there correctly,
intuitively and user-friendly.
Portability to other platforn is not something everyone seeks, and if so do
not want to sacrifice anything for unused generality.