Re: Exception Misconceptions
On Dec 21, 8:31 am, "io_x" <a...@b.c.invalid> wrote:
"James Kanze" <james.ka...@gmail.com> ha scritto nel
messaggionews:4f3858fa-d8e2-4c92-970f-ae4d6d9913cc@s31g2000yqs.googlegroups.com...
On Dec 19, 4:51 pm, "io_x" <a...@b.c.invalid> wrote:
"tanix" <ta...@mongo.net> ha scritto nel
messaggionews:hgg839$ot7$1@news.eternal-september.org...
In article
<3eacbb7a-4318-4fed-b71c-f5da24cfa...@s20g2000yqd.googlegroups.com>, James
Kanze <james.ka...@gmail.com> wrote:
Wasting weeks on cleaning up the memory leaks? I have
wasted MONTHS on trying to catch all the subtle memory
leaks in a sophisticated async based program because of
some network availability issues make you maintain all
sorts of queues, depending on user interaction, causing
such headaches, that you can not even begin to imagine
from the standpoint of memory leaks.
do you know, exist wrapper for malloc, that at end of the
program check if there are "memory leak" and report the
result to the screen
If the program ends, it doesn't leak memory, and
practically, there's no way any tool can tell whether there
is a leak or not.
if there is "no way any tool can tell whether there is a leak
or not" that programming language has one all you call
"designed error" because can eat memory more than is
sufficient because all you can not have the controll on memory
Determining whether there is a leak or not is comparable to the
stopping problem. It's been more or less proven that it can't
be computed.
(Well, they can tell that some things are definitively
leaked. If there are no pointers to the memory, for
example, it has leaked.) What the tools do is suggest
possible leaks.
With regards to the first statement, of course: I've worked
on a fairly large number of applications which didn't leak.
so in the first statemt you say:
"there's no way any tool can tell whether there is a leak or
not" in the other you say "I've worked on a fairly large
number of applications which didn't leak."
so do how you can be sure?
After the code has run five or more years in a low memory
environment, you can feel pretty sure.
But yes, there's a strict sense that you can never been 100%
sure.
Note that I'm not against using tools. The fact that they can't
find 100% of the leaks doesn't mean that they're without value.
(On the other hand, typically, the tools I've used, like
Rational Rose, have shown that dangling pointers are more of a
problem than leaks.)
if pass some of your programs with some "leak print at end"
program possibily find some leak (or you OS-compiler allow to
see if one program has some leak (not free all memory) )
for my little programs in my enviroment i'm sure for the
memory of the malloc wrapper (not for the memory released from
"new" (i never use it but should be used from the compiler or
for static object if i rember well))
Note that some of the programs are very inaccurate. (This does
not hold for valgrind or Rational Rose, which are careful to
document exactly what they've found, and what it might or might
not mean.)
Some of them, you may have used, without knowing it, since
many of the programs I've worked on aren't visible to the
user---they do things like routing your telephone call to
the correct destination. (And the proof that there isn't a
leak: the program has run over five years without running
out of memory.)
possibily the leak is small and/or in some corner case
Possibly. Or possibly, we used good design, and careful design
and code review, and there really aren't any leaks.
[...]
In the end, good software engineering is the only solution.
Thus, for example, I prefer using garbage collection when I
can, but it's a tool which reduces my workload, not
something which miraculously elimninates all memory leaks
(and some of the early Java applications were noted for
leaking, fast and furious).
are you sure is it good for think less?
Who said anything about thinking less?
are you sure is it good for not doing formal
correct memory allocation-deallocations?
It's certainly good to have less lines of code to write and
to debug. And to be able to use the time that would be
otherwise required for those lines of code to do something else,
like more intensive testing, or adding a feature.
--
James Kanze