Re: pointer components and memory leaks
- From: Damian <damian@xxxxxxxxxx>
- Date: Wed, 17 Sep 2008 02:49:14 -0700 (PDT)
On Sep 17, 12:36 am, "mreste...@xxxxxxxxx" <mreste...@xxxxxxxxx>
wrote:
On 16 Sep., 21:13, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
Paul van Delst <Paul.vanDe...@xxxxxxxx> wrote:
Richard Maine wrote:
mreste...@xxxxxxxxx <mreste...@xxxxxxxxx> wrote:
...Dear all,
is there a way to overload the operators +, =, ... for a derived
type with pointer components which does not leak memory?
and I still get the memory leak in tt_sum. It seems to me that this...
example will always leak somewhere inbetween the "+" and the "=".
(only tried one compiler)
The line
c=a+b
first calls tt_sum to do the "a+b" bit. Then tt_def is called to do the
"c=..." bit. But what(or where) is the rhs of the assignment? The z result
of tt_sum becomes the x input of tt_def...but where does the x input of
tt_def "go" after the assignment is done?
Crikey, trying to explain what I think I mean is confusing me.
That's ok. I'm following, at least adequately. I had forgotten all the
details, but I think you are right in that you also need a final
procedure to make that work without leaks. I haven't checked the exact
rules, but that's bound to be a context in which a final procedure is
invoked; anyway, it better be, that being one of the points of them. The
result of a+b is a temporary, which "goes away" after the assignment.
Final procedures are supposed to be called whenever something "goes
away" (though, of course, that's not the formal terminologuy used).
Richard, Paul,
thank you for the illuminating comments. My question originated
while working on a rather large code which predates the TR 15581,
where many pointers components "would like" to be allocatables... but
they are not. I was focusing on the issue of the temporary, but indeed
after reading Richard Maine's post I see many other potential issues,
which are addressed in Paul van Delst's version of the code. All in
all, I think that for the time being I will use a somewhat more
conservative approach with dedicated procedures to make sums and
assignment, avoiding the overloaded operators, and thus temporary
objects (being careful about initializations and deallocations!).
Marco
Before you give up, there are approaches that will probably help. The
simplest thing to do is to direct you to papers that explain these
approaches. A list of references is at bottom of this post. The
basic idea is you need to add a component that tags temporary derived
type objects for deletion. Then you need an algorithm for determining
which objects are temporary. You will also need to use nested derived
types. The types you pass around will be shells containing only the
above tag and a pointer to the actual type containing your data. This
will help you get around the "intent(in)" requirement for defined
operators. I have made this approach work with every compiler I've
tried, including Intel, IBM, gfortran, g95, and PGI.
I haven't read every line of every post in this thread, but it's still
not clear to me why you can't use allocatable components. This would
solve your problem as long as you're using the latest version of one
of the above compilers (prior versions of Intel and PGI had leaks with
allocatable components used in the way you're using them).
Nonetheless, the approaches discussed in the papers cited below will
work just fine for pointers.
For a relatively simple approach that works in most circumstances, see
Rouson, D.W.I., Xu, X. and Morris, K. “Formal constraints on memory
management for
composite overloaded operations,” Scientific Programming, 14:1, 27-40
(2006).
Rouson, D.W.I, Morris, K. and Xu, X. “Dynamic memory de-allocation in
Fortran 95/2003 derived
type calculus”, Scientific Programming , 13:3, 189-203. (2005).
For a more involved approach that works in the cases when the above
one fails, see the references below. They explain an approach known in
the object-oriented programming community as "reference counting."
G.W. Stewart, Memory leaks in derived types revisited, ACM Fortran
Forum 22(3) (December 2003).
A. Markus, Avoiding memory leaks with derived types, ACM Fortran Forum
22(2) (August 2003).
Lastly, I'm really glad you posted this. As previously noted, the
style of your code is unusual in Fortran, but it is very common in
other object-oriented languages. I believe one of the reasons it is
less common in Fortran is that the compiler vendors have been so slow
to implement Fortran 2003, which will obviate the need for any of the
above algorithms. They say it's because people aren't asking for the
features that would help (such as final procedures), but I suspect
there are many users who try this style of programming only to suffer
in silence and ultimately abandon the style or abandon Fortran -- both
of which I consider tragic.
Damian
.
- References:
- pointer components and memory leaks
- From: mrestelli@xxxxxxxxx
- Re: pointer components and memory leaks
- From: Richard Maine
- Re: pointer components and memory leaks
- From: Paul van Delst
- Re: pointer components and memory leaks
- From: Richard Maine
- Re: pointer components and memory leaks
- From: mrestelli@xxxxxxxxx
- pointer components and memory leaks
- Prev by Date: Re: Reading external variables from a library (BIND)
- Next by Date: Re: pointer components and memory leaks
- Previous by thread: Re: pointer components and memory leaks
- Next by thread: Re: pointer components and memory leaks
- Index(es):
Relevant Pages
|
