A question about deallocate() and others in Fortran
Fortran Learner
following:
What is the difference between the deallocate() and nullify() function
in Fortran 90?
And what is the difference among the allocate(), => and = operator for
the pointer variable?
I meet some quite serious problem in my program. There are even some
very stranger problem,
Before I want to deallocate a pointer varibale, I use a associated()
function to test it. The resutl for this function is true, but when I
try to deallocate it an error occured.The error ifnormation such like
that: allocatable array or pointer is not allocated.
I am amuszing, why the test function associated() is true?
I also found that the pointer can be allocated several times. And every
time been allocated, the previous memory space assciated by the pointer
will inaccessible. It could be a possible way to memory leak. Is this a
bug in fortran standard? if not, may be my logical doesn't work.
In my program, there are various pointer variable, after an complicated
calculation ,even for me it's not easy to free them.
Please give me more information about it. Thank you very much.
Craig Powers
> Hi, Nice to be here. I am a beginer in Fortran, So I want to know the
> following:
> What is the difference between the deallocate() and nullify() function
> in Fortran 90?
Deallocate does what it says, deallocates memory and returns it to the
Fortran RTL memory manager (which may in turn return it to the system,
or retain it to satisfy potential future allocation requests).
Nullify puts a pointer in a well-defined "cleared" assocation status.
If the pointer is associated with a block of allocated memory, nullify
does not (AFAIK) deallocate the memory.
> And what is the difference among the allocate(), => and = operator for
> the pointer variable?
For a pointer variable, allocate will allocate a block of memory and
associate it with the pointer variable.
=> will change the association of the pointer variable to associate it
with something else (whatever is on the RHS of the statement)
= will assign to whatever is associated with the pointer.
> I meet some quite serious problem in my program. There are even some
> very stranger problem,
> Before I want to deallocate a pointer varibale, I use a associated()
> function to test it. The resutl for this function is true, but when I
> try to deallocate it an error occured.The error ifnormation such like
> that: allocatable array or pointer is not allocated.
>
> I am amuszing, why the test function associated() is true?
If the pointer is associated with a variable, rather than an allocated
block of memory, then you would not be able to allocate it. No other
issues spring to mind.
> I also found that the pointer can be allocated several times. And every
> time been allocated, the previous memory space assciated by the pointer
> will inaccessible. It could be a possible way to memory leak. Is this a
> bug in fortran standard? if not, may be my logical doesn't work.
I wouldn't say it's a bug, exactly. It'd be more correct to say that
the main reason you might want to use this feature (only way to do
allocatable components of a derived type in F95) is a bug, which was
corrected with a TR that has been incorporated into F2003 and
implemented in most F95 compilers.
Michael Metcalf
"Craig Powers" <eni...@hal-pc.org> wrote in message
news:45241887$0$40072$a726...@news.hal-pc.org...
>> I meet some quite serious problem in my program. There are even some
>> very stranger problem,
>> Before I want to deallocate a pointer varibale, I use a associated()
>> function to test it. The resutl for this function is true, but when I
>> try to deallocate it an error occured.The error ifnormation such like
>> that: allocatable array or pointer is not allocated.
>>
>> I am amuszing, why the test function associated() is true?
>
> If the pointer is associated with a variable, rather than an allocated
> block of memory, then you would not be able to allocate it. No other
> issues spring to mind.
Remember that a pointer is created with the status of 'undefined association
status'. To get it in a defined state, it must be allocated, pointer
assigned (=>) or nullified. Before any of these occurs, the status may not
be tested with associated. In general, pointers should be given a defined
status as early in the program as possible, where possible by initialization
as in
integer, pointer :: kkk=>null()
or otherwise as in
nullify(kkk)
Regards,
Mike Metcalf
glen herrmannsfeldt
> Remember that a pointer is created with the status of 'undefined
> association status'. To get it in a defined state, it must be
> allocated, pointer assigned (=>) or nullified. Before any of these occurs,
> the status may not be tested with associated. In general, pointers
> should be given a defined status as early in the program as possible,
> where possible by initialization as in
> integer, pointer :: kkk=>null()
As we have been discussing for days, does this cause kkk
to be SAVEd?
This might be one case where I would want it null() each
time through a subprogram. That is, unless one actually
wanted to keep it between calls.
-- glen
Richard E Maine
add answers to some of the things that he didn't.
Fortran Learner <ding.xia...@gmail.com> wrote:
> Hi, Nice to be here. I am a beginer in Fortran,
My first, and probably most important comment is that pointers are *NOT*
a good thing to start out with. Pointers provide many extra
opportunities for error and confusion, even for experiences users of the
language.
The answers here aren't going to be enough to make you proficient in
using pointers.
> What is the difference between the deallocate() and nullify() function
> in Fortran 90?
As Craig said, deallocate frees the space. Nullify does nothing to the
allocated space. It just makes that pointer not point to that space any
more. I can see that you are missing one of the most fundamental ideas
of what pointers are about in the first place. In fact, I can see that
trend inmost of these questions. More on that below.
> And what is the difference among the allocate(), => and = operator for
> the pointer variable?
Allocate allocates a new target and makes the pointer point to it.
Pointer assignment (the =>) makes the pointer point to some existing
target. Ordinary assignment (the =) assigns data to the target.
> Before I want to deallocate a pointer varibale, I use a associated()
> function to test it...
Ok. Stop right there. A major and common problem. Pointers can be in one
of *THREE* states. Yes, that is three, not two. A pointer can be
associated, nullified (aka disassociated), or its association status can
be undefined. The associated intrinsic can *ONLY* distinguish between
associated vs null. It is illegal to even use the associated intrinsic
on a pointer whose status is undefined. If you do that, then your
program is ilegal and pretty much anything can happen. That can
definitely include giving bogus results from the intrinsic. That's one
of the many things that makes pointer usage tricky. It is your
resposability as the programmer to make sure that you know that the
pointer can't be undefined when you use the associated intrinsic. There
is no standard way to inquire about that; you just have to know all the
rules (which are way too much to go into here). But the first rule is
that pointers normally start out in the undefined state. So if the first
thing you do with a pointer is use the associated function on it, that
is an error there.
> I also found that the pointer can be allocated several times. And every
> time been allocated, the previous memory space assciated by the pointer
> will inaccessible. It could be a possible way to memory leak. Is this a
> bug in fortran standard? if not, may be my logical doesn't work.
Ah. This is what makes it clear to me that you have missed what pointers
are about. Because this is fundamental to the whole idea. I think you
are probably looking for allocatables instead of pointers. The most
fundamental difference between the two (there are many, many
consequences, but I'd say this one is the most fundamental) is that an
allocatable variable is uniquely tied to the space allocated for it.
That space "belongs" to the variable. If the variable "goes away" for
any reason, so does the space. By design, allocatables cannot leak
memory.
A pointer, on the other hand, does not uniquely "own" any allocation. It
can point to a target, but the target has existance completely
independent of the pointer. When you "allocate a pointer", you really do
2 things, although in one statement. First, you allocate a target. Then
you make the pointer point to that target. But the pointer and its
target are still separate things and can go their own ways. Just because
you do something like allocate the pointer again, that doesn't mean the
old target goes away. You don't want the old target to go away... or if
you do want that, then what you want is an allocatable instead of a
pointer. There might be other pointers pointing to that target. I could
elaborate on that, but... it takes a bit of time to do well; books will
do it better than anything I could write on the fly in a posting; and I
really, really think this is probably all irrelevant because you are
probably looking at the wrong tool anyway.
Your questions strongly suggest to me that you are thinking about
alocatables and wondering why pointers don't act like allocatables.
Allocatables has limitations that sevverely handicapped their use in
f90, and even in f95 prior to the so-called allocatable TR. It is
possible to use pointers as a substitute for allocatables as an interim
measure. But it does cause several confusions and it is important to
understand how they are different. That gets into quite a bit more. I
know I haven't explained that adequately, but this is long enough
already, I'm short on time, and with any luck it is all irrelevant
because you can switch to allocatables instead.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Michael Metcalf
"glen herrmannsfeldt" <g...@seniti.ugcs.caltech.edu> wrote in message
news:eg1886$oc6$1...@naig.caltech.edu...
> Michael Metcalf <michael...@compuserve.com> wrote:
>
>> Remember that a pointer is created with the status of 'undefined
>> association status'. To get it in a defined state, it must be
>> allocated, pointer assigned (=>) or nullified. Before any of these
>> occurs,
>> the status may not be tested with associated. In general, pointers
>> should be given a defined status as early in the program as possible,
>> where possible by initialization as in
>
>> integer, pointer :: kkk=>null()
>
> As we have been discussing for days, does this cause kkk
> to be SAVEd?
>
within a type definition, it becomes a *default* initialization with
different semantics, see "Fortran 95/2003 Explained", Sections 7.5.3 and
7.5.4.)
Regards,
Mike Metcalf
John Harper
Craig Powers <eni...@hal-pc.org> wrote:
>
>I wouldn't say it's a bug, exactly. It'd be more correct to say that
>the main reason you might want to use this feature (only way to do
>allocatable components of a derived type in F95) is a bug, which was
>corrected with a TR that has been incorporated into F2003 and
>implemented in most F95 compilers.
Just yesterday I tested g95 on that in the array (not pointer)
context. That compiler deals with the following program as described
in the first 3 comment lines, as it should.
! Q. Are allocatable components OK in a type declaration?
! A. Not in f95 unless TR15581 is followed, so this program won't
! compile with g95 -std=f95 but will with g95 -std=f95 -ftr15581
!
MODULE myProject
TYPE myData
REAL , ALLOCATABLE :: values(:)
END TYPE myData
END MODULE myProject
! ----------------------------------------
PROGRAM TEST
USE myProject
TYPE(myData) :: data
ALLOCATE(data%values(3))
data%values = (/2,4,6/)
WRITE(*,*) data%values
END PROGRAM TEST
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Fortran Learner
Thanks about all the reply above.
I got it. Until now, I am begin to clear about the fundemental concept.
:)
Actually, I had debug my program last night, and I found most of all
the memory leak in my program are caused by undefined pointer. As
mentioned by Craig Powers and Richard E Maine, every pointer has three
status. Before any using of an pointer, the status of the pointer
should be undefined. So, if tested by associated(), the result should
unpredictable and will lead memory leak. This is the main problem in my
program.
Thank you all, anyway, I had learn many fundemental concept here.
Tobias Schlemmer
Let's try it to explain how a C programmer would do it (for me the
fortran descriptions are always very confusing).
A Pointer in computer science is a number describing a memory position.
In Fortran it can be accessed in two cases:
1. as pointer
2. as Reference to the data at the position it points to.
Fortran Learner wrote:
> Hi, Nice to be here. I am a beginer in Fortran, So I want to know the
> following:
> What is the difference between the deallocate() and nullify() function
> in Fortran 90?
nullify sets the pointer pointing to a definite non existent memory
position. Let's say it is 0. In fact it will be 0 in most cases as C
does use this value for none associated pointers.
deallocate frees the space where the pointer points to, but doesn't
change the pointer. So the pointer will look like pointing to a memory
position, which is no longer owned by the program. But the memory can be
used again for other programs/variables.
> And what is the difference among the allocate(), => and = operator for
> the pointer variable?
=> changes where the pointer points to
= sets the value of the memory position referenced by the pointer
> I meet some quite serious problem in my program. There are even some
> very stranger problem,
> Before I want to deallocate a pointer varibale, I use a associated()
> function to test it. The resutl for this function is true, but when I
> try to deallocate it an error occured.The error ifnormation such like
> that: allocatable array or pointer is not allocated.
Either the pointer is not initialized or it was freed, but not set to 0.
So the program has no chance to detect, that the pointer does not point
to a proper memory position.
> I am amuszing, why the test function associated() is true?
Associated only tests if the pointer is 0.
> I also found that the pointer can be allocated several times. And every
> time been allocated, the previous memory space assciated by the pointer
> will inaccessible. It could be a possible way to memory leak. Is this a
> bug in fortran standard? if not, may be my logical doesn't work.
No. This is the major advantage of using pointers over allocatable
variables. Consider
type list
integer:: value
type(list),pointer :: next
end type
type(list),pointer :: root, element
so you can create a list of several elements:
allocate(root)
root % next = null() ! end of list marker
root % value = 1
allocate(element)
element % next => root
element % value = 2
root % element
allocate(element)
element % next => root
element % value = 3
root % element
Now root points to a linked list:
root -> {3} -> {2} -> {1} -> 0
(the last 0 is the null() pointer). All three elements are still in memory.
> In my program, there are various pointer variable, after an complicated
> calculation, even for me it's not easy to free them.
That's a common problem with pointers. For our linked list we must do
the following:
do while (associated(root))
element => root
root => root % next
deallocate(element)
end do
That will delete all elements. Remember the last next pointer has been
nullified.
> Please give me more information about it. Thank you very much.
Maybe you should have a look to C or Pascal literature to get some
intuition about pointers. In that languages pointers are common
practise. In Fortran the pointer type has a mixed semantics: some of it
is pointer and some is reference.
Tobias
Richard E Maine
> deallocate frees the space where the pointer points to, but doesn't
> change the pointer. So the pointer will look like pointing to a memory
> position, which is no longer owned by the program.
That is incorrrect, although it seems a common misconception. In
addition to freeing the space, deallocate also leaves the pointer
nullified. After all, there is no reason for it not to. This isn't one
of the kinds of situation where it is any work at all to make the
pointer correctly reflect reality.
I have fairly often seen the construct
deallocate(p)
nullify(p)
The nullify there is completely redundant.
glen herrmannsfeldt
(snip on deallocate and pointers)
> That is incorrrect, although it seems a common misconception. In
> addition to freeing the space, deallocate also leaves the pointer
> nullified. After all, there is no reason for it not to. This isn't one
> of the kinds of situation where it is any work at all to make the
> pointer correctly reflect reality.
But what about copies of the pointer?
> I have fairly often seen the construct
> deallocate(p)
> nullify(p)
> The nullify there is completely redundant.
In C, with call by value, the free() function only
gets a copy of the pointer. In that case, if you
expect to test for null you need to assign null
after the call to free().
For Java, which uses garbage collection instead of
free/deallocate the way to directly free memory is
to assign null to an object reference variable
(the Java name for a pointer).
-- glen
Richard E Maine
> Richard E Maine <nos...@see.signature> wrote:
> (snip on deallocate and pointers)
>
> > That is incorrrect, although it seems a common misconception. In
> > addition to freeing the space, deallocate also leaves the pointer
> > nullified. After all, there is no reason for it not to. This isn't one
> > of the kinds of situation where it is any work at all to make the
> > pointer correctly reflect reality.
>
> But what about copies of the pointer?
Yes? What about them? They are not the subject of the quoted para. They
are different things. The above para has nothing to do with them. I
suppose I could branch off onto a tutorial of everything about pointers,
but I don't feel inclined to do so. There are plenty of good books with
coverage of the subject. I was only correcting a specific misstatement.
If you somehow think that this bears directly on the accuracy of my
comment, then that is incorrect; it does not. If you are branching off
onto a more general discussion, then that's fine, but I'll decline to
follow (and I might wish that the change of subject were more explicit;
I have trouble telling from the above whether one was intended or not).
By the way, strictly speaking, there is no such thing as a "copy" of a
pointer. There might be other pointers with the same target. While one
might say that this is word quibble, it is a quibble that might help
avoid confusions such as the one that this question illustrates if it
was notr intended to be a change of subject.
glen herrmannsfeldt
> glen herrmannsfeldt <g...@seniti.ugcs.caltech.edu> wrote:
>> Richard E Maine <nos...@see.signature> wrote:
>> (snip on deallocate and pointers)
> Yes? What about them? They are not the subject of the quoted para. They
> are different things. The above para has nothing to do with them. I
> suppose I could branch off onto a tutorial of everything about pointers,
> but I don't feel inclined to do so.
For the subject of possible ways to go wrong while using pointers,
keeping a copy of a pointer is one way.
> There are plenty of good books with
> coverage of the subject. I was only correcting a specific misstatement.
> If you somehow think that this bears directly on the accuracy of my
> comment, then that is incorrect; it does not.
Clarifying the range of the statement.
(snip)
> By the way, strictly speaking, there is no such thing as a "copy" of a
> pointer. There might be other pointers with the same target. While one
> might say that this is word quibble, it is a quibble that might help
> avoid confusions such as the one that this question illustrates if it
> was notr intended to be a change of subject.
Different languages work with pointers in different ways.
Java is somewhat different as far as pointers (object reference
variables), as one example.
Thanks for the clarification.
-- glen