On Sep 17, 12:36 am, "mreste...@
gmail.com"
gmail.com>
wrote:> On 16 Sep., 21:13, nos...@see.signature (Richard Maine) wrote:
>
>
>
>> Paul van Delst
noaa.gov> wrote:>
>>> Richard Maine 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
