In article <e8775871-ff98-4615-84fe-165b8404d8fe@t42g2000yqd.googlegroups.com>, James Kanze <james.kanze@gmail.com> wrote:
On Dec 20, 2:30 pm, "Balog Pal" <p...@lib.hu> wrote:
"James Kanze" <james.ka...@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).
But I don't claim that there's any one coding solution that will
solve all my problems. The only thing I'm objecting to in your
posting is "*JUST* use a manager[...]". That's not a silver
bullet; if proper design says to use a manager or a smart
pointer for some things, then it is good. But we don't want to
see the tail wagging the dog. And even the ultimage memory
manager, garbage collection, doesn't result in no leaks.
Not true. Well THEORETICALLY true.
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.
Something got garbled in your last sentence, and I'm unable to
parse it. But in practice, I find that with proper OO design,
*in* *C++*, you really don't need a manager, a smart pointer, or
garbage collection that often. Most objects which can't manage
themselves have value semantics, and aren't allocated on the
heap to begin with. (Of course, applications may vary, and I've
seen applications where extensive use of smart pointers was
justified. It's just not a general rule.)
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. ;-)
Not usually. First, C++ uses a lot less dynamic allocation to
begin with than languages like Java. And secondly, it's usually
preferable (albeit not always possible) to ensure that your
objects are fully capable of managing themselves before
returning from the constructor.
[...]
(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.
Yes. I mention it because one poster suggested that memory
leaks were impossible in Java, because of garbage collection.
And because early versions of Swing had just such a leak. (Note
that competent Java programmers don't make such dubious claims.
And that Sun did recognize it as a leak.)
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.
Yes. For a lot of applications, it really doesn't matter. From
what he's described, however, I think that it would in this one.
In which case, garbage collection probably isn't appropriate.
Actually did anyone heard a reporting firewall implemented in
java?
I think I've seen one. It tends to occupy over a GB, and takes
90% of the CPU.
[...]
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...
Handling different languages is difficult, regardless of the
language. But I found that the "auto-layout" in Java simplified
the task. (Admittedly, I ended up writing a couple of custom
layout managers. But it wasn't that big a job.)
[...]
That keeps me generally sceptic wrt GUI portability. Without
a big deal of manual work at the QA dept and coding too...
Like everything, it requires up front design.