Dear all,
is there a way to overload the operators +, =, ... for a derived
type with pointer components which does not leak memory?

To be more precise, the attached code, according to valgrind, leaks
the memory allocated in tt_sum (which indeed seems reasonable to me).
Is there a way to rearrange this code to avoid memory leaks?

I have to add that 1) in general I can not switch to allocatable
components 2) I think a FINAL procedure might solve the problem, but I
wonder how many compilers support it.

Thank you for any advice,
Marco

module mm

implicit none

type tt
real, pointer :: x(:)
!real, allocatable :: x(:)
end type tt

mrestelli@gmail.com gmail.com> wrote:

Well, you've ruled out the easy one, namely to make it allocatable. It
really looks like pointer is being used as a surrogate for allocatable
here.

Other than that, you could test whether the component is associated
before allocating a new one. Deallocate any old one. But this requires
*LOTS* of care to get it all right. Two basic things.

Richard Maine wrote:

Paul van Delst noaa.gov> wrote:

On Sep 16, 2:40 pm, Paul van Delst noaa.gov> wrote:

rusi_pathan gmail.com> wrote:

Yes, that's the same thing as what Paul said. Perhaps you are looking at
the variable from different perspectives. It is "created" as the z in
tt_sum and then used as the x in tt_def that Paul mentioned. But its the
same thing.

Let's not suggest compiler bug every time one finds a problem. While
compilers have been known to have bugs, those people who first think
compiler bug every time they see something wrong don't tend to do a very
good job of debugging... because they too quickly stop looking for their
own bugs, which are where most bugs are, after all. Calling "compiler
bug" too quickly is a habit that often has to be "beat out" of new
users. There sometimes seems to be an inverse correlation in that the
people who most often suggest they have found compiler bugs are the
people least likely to have actually done so.

Richard Maine wrote:

I agree (i.e. it's not a compiler bug). To be honest, the behaviour seems quite reasonable.

Annoyingly leaky, perhaps, but reasonable.

It's got me beat to figure out how to make it *not* leak - how to deallocate the temporary
result of a+b?

A very illuminating example. It's getting copied into my examples folder (uh, er, I mean
"directory" :o)

Paul van Delst noaa.gov> wrote:

Note the previous mention of final procedures. This is the kind of
reason they were added to the language. (It was also part of the reason
why they stayed, even when initial procedures were tossed; final
procedures had fewer complicatyions and were more necessary... for
things like this... whereas initial procedures were mostly just a
convenience).

In particular... I suppose I might as well go check... looks like in
f2003, 4.5.5.2,\"When finalization occurs", 3rd para

"If an executable construct references a function, the result is
finalized after execution of the innermost executable construct
containing the reference."

So in this case, the function result of a+b (that's a function
reference) is finalized after execution of the assignment statement
(which is the innermost executable construct containing the reference).
If you have a suitable final procedure, that's its opportunity to "clean
up" by deallocating the pointer component if appropriate.

"Richard Maine" wrote in message
news:1ind27e.1ueeefs1lcziqcN%%nospam@see.signature...

James Van Buskirk comcast.net> wrote:

Yes, but I'll claim that you are a bit of a special case (in a good way
- not meant to be derogatory) and not particularly representative of the
majority of Fortran programmers.