Board index » cppbuilder » Re: BCB Delphi IDE

Re: BCB Delphi IDE


2004-10-23 09:49:56 PM
cppbuilder98
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:
[snip]
Quote
But others who have used GCs can tell you that you usually don't have
to worry about memory release. It will be done when necessary.
`Usually' is a very convenient word for everything :-)
The truth is that GC doesn't prevent memory leaks.
[A memory leak happens when a user forgets to release memory (manual
MM) or when a GC is unable to release memory (automatic MM) that is
not used on the rest of the lifetime of the program. The na´ve concept
of memory leak others used on this thread is not correct. Having
non-freed memory resources at the end of the program's lifetime
doesn't necessarily implies a leak]
--
Oscar
 
 

Re:Re: BCB Delphi IDE

Oscar Fuentes wrote:
Quote
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:

[snip]

>But others who have used GCs can tell you that you usually don't
>have to worry about memory release. It will be done when necessary.

`Usually' is a very convenient word for everything :-)

The truth is that GC doesn't prevent memory leaks.
A seatbelt or airbag do not prevent all deaths in traffic either. And
yet most people think they are useful.
A GC can not prevent all possible memory leaks, but it prevents the
most common ones. This does not completely free the programmer from his
or her responsibilities.
Quote
[A memory leak happens when a user forgets to release memory (manual
MM) or when a GC is unable to release memory (automatic MM) that is
not used on the rest of the lifetime of the program.
If the GC is not able to release memory, it is because the code is
still holding a reference to it. Blame the programmer.
--
Rudy Velthuis [TeamB]
"A man can't get rich if he takes proper care of his family."
- Navaho saying.
 

Re:Re: BCB Delphi IDE

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:
[snip]
Quote
A GC can not prevent all possible memory leaks, but it prevents the
most common ones. This does not completely free the programmer from his
or her responsibilities.
Exactly. The problem is that lots of programmers thinks GC relieves
them from thinking about memory handling, when the truth is that GC
just makes things easier.
The situation is identical to the misinformation about .NET and
security: there are lots of people (I'll say *most* programmers) who
thinks that .NET makes applications secure and they have no reason to
care anymore about security.
The existence of these misunderstandings often produces applications
that requires inordinate amounts of memory and that are easily
breakable. So this is a case where having more advanced tools helps to
produce poorer products.
I think the main culprits about the misunderstandings are the
companies that pushed Java and now .NET as technological revolutions,
where in fact there is nothing new behind them. Sun and MS just took
advantage of people's ignorance tooting GC, VMs and checked access as
"solutions", when in fact they are just aids.
[snip]
--
Oscar
 

{smallsort}

Re:Re: BCB Delphi IDE

Oscar Fuentes wrote:
Quote
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:

[snip]

>A GC can not prevent all possible memory leaks, but it prevents the
>most common ones. This does not completely free the programmer from
>his or her responsibilities.

Exactly. The problem is that lots of programmers thinks GC relieves
them from thinking about memory handling, when the truth is that GC
just makes things easier.
Actually there are not many situations where it can't handle memory,
except in the case of global or semi-global variables.
--
Rudy Velthuis [TeamB]
"It's not that I'm afraid to die, I just don't want to be there
when it happens." -- Woody Allen, From 'Death' 1975.
 

Re:Re: BCB Delphi IDE

Rudy,
According to my experience those are not the most common one. The
most common one are not release references, and indeed the non
deterministic GC does reduce the chances of detecting and fixing them.
Now don't get me wrong, I love the idea of GC, the non deterministic
part is what bothers me.
With best regards,
Boian
Rudy Velthuis [TeamB] wrote:
Quote
A GC can not prevent all possible memory leaks, but it prevents the
most common ones. This does not completely free the programmer from his
or her responsibilities.

 

Re:Re: BCB Delphi IDE

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
>Exactly. The problem is that lots of programmers thinks GC relieves
>them from thinking about memory handling, when the truth is that GC
>just makes things easier.

Actually there are not many situations where it can't handle memory,
except in the case of global or semi-global variables.
Most applications have *state* that lives as much as the application
itself, plus data structures and data relations that are quite
complex. My experience says that a common GC'ed application has big
chances of suffering from memory leaks if you forget about studying
the relations among session-life state and procedure-life state.
--
Oscar
 

Re:Re: BCB Delphi IDE

Oscar Fuentes wrote:
Quote
Most applications have state that lives as much as the application
itself, plus data structures and data relations that are quite
complex. My experience says that a common GC'ed application has big
chances of suffering from memory leaks if you forget about studying
the relations among session-life state and procedure-life state.
Of course, if one needs the session-life state info during the entire
session, one can hardly consider it a leak. If one doesn't, it
shouldn't be session-life.
--
Rudy Velthuis [TeamB]
"Everywhere I go I'm asked if I think the university stifles writers.
My opinion is that they don't stifle enough of them."
- Flannery O'Connor (1925-1964)
 

Re:Re: BCB Delphi IDE

Boian Mitov wrote:
Quote
I love the idea of GC, the non
deterministic part is what bothers me.
Why actually? If you have other resources that must be released, you
still do the same thing as without a GC. Perhaps with a slightly
different syntax of setup, but the ideas still apply.
--
Rudy Velthuis [TeamB]
"Researchers have discovered that chocolate produces some of the same
reactions in the brain as {*word*185}. The researchers also discovered
other similarities between the two but can't remember what they are."
-- Matt Lauer on NBC's Today Show .
 

Re:Re: BCB Delphi IDE

No! I use destructor. I can't use it in .NET as there is no
destructor! So it is completely different ball game. It is like
switching from C++ back to the old C days. Not to mention the complexity
of debugging when each run with the same condition results in different
execution, as the GC will call the finalizers different way each time no
mater how well you are trying to reproduce the condition. You can forget
about the term reproducible case under the current .NET implementation,
the same as in Java.
Switching from C++ to .NET is returning the clock to 14 years old
development practices, plus additional complexity in case reproduction.
Sweet ;-) . I am looking forward indeed as those are some of my areas of
strength, so I guess more work for me ;-)
Rudy Velthuis [TeamB] wrote:
Quote
Boian Mitov wrote:


>I love the idea of GC, the non
>deterministic part is what bothers me.


Why actually? If you have other resources that must be released, you
still do the same thing as without a GC. Perhaps with a slightly
different syntax of setup, but the ideas still apply.
 

Re:Re: BCB Delphi IDE

Boian Mitov wrote:
Quote
No! I use destructor. I can't use it in .NET as there is no
destructor!
Depending on the language, the destructor either maps to the finalizer
(C#), or to Dispose (Delphi).
C# users are told to have a Dispose(boolean) function which is called
with true in the finalizer and false in Dispose.
Delphi users simply do what they always did. They put the code that
frees resources in the destructor.
I have no idea how this is is done in C++/CLI (or Managed C++).
--
Rudy Velthuis [TeamB]
"Everything that can be invented has been invented."
-- Charles H. Duell, Commissioner, U.S. Office of Patents, 1899
 

Re:Re: BCB Delphi IDE

Boian Mitov wrote:
Quote
No! I use destructor. I can't use it in .NET as there is no
destructor! So it is completely different ball game. It is like
switching from C++ back to the old C days. Not to mention the
complexity of debugging when each run with the same condition results
in different execution, as the GC will call the finalizers different
way each time no mater how well you are trying to reproduce the
condition.
IMO you should not use destructors, then, but use Dispose instead.
--
Rudy Velthuis [TeamB]
"The covers of this book are too far apart."
- Ambrose Bierce (1842-1914)
 

Re:Re: BCB Delphi IDE

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
>Most applications have state that lives as much as the application
>itself, plus data structures and data relations that are quite
>complex. My experience says that a common GC'ed application has big
>chances of suffering from memory leaks if you forget about studying
>the relations among session-life state and procedure-life state.

Of course, if one needs the session-life state info during the entire
session, one can hardly consider it a leak. If one doesn't, it
shouldn't be session-life.
Nope. It is about creating references from session-life state to
procedure-life state, and forgetting the destruction of those
references. Such procedure-life memory is not released. (Procedure not
in the sense of Delphi's procedure or function keywords, but in the
sense of something whose lifetime is enclosed inside the lifetime of a
longer lived object).
Early on this thread several good examples were showed.
--
Oscar
 

Re:Re: BCB Delphi IDE

Oscar Fuentes wrote:
Quote
Nope. It is about creating references from session-life state to
procedure-life state, and forgetting the destruction of those
references.
Now you lost me. An example would make it clearer I guess.
--
Rudy Velthuis [TeamB]
"Small minds run in the same gutter."
-- Alfred E. Neuman
 

Re:Re: BCB Delphi IDE

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
Oscar Fuentes wrote:

>Nope. It is about creating references from session-life state to
>procedure-life state, and forgetting the destruction of those
>references.

Now you lost me. An example would make it clearer I guess.
As I'm lazy, I'll reuse the examples Gillmer posted:
groups.google.com/groups&lr=&selm=41769130%40newsgroups.borland.com&rnum=1
or
tinyurl.com/66b2p
More examples on demand :-)
--
Oscar
 

Re:Re: BCB Delphi IDE

Boian Mitov wrote:
Quote
No! I use destructor. I can't use it in .NET as there is no
destructor! So it is completely different ball game. It is like
switching from C++ back to the old C days.
Well, the next version of VC++ is going to fix this...