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
