Environments, Tables, And Troff Macros - nullify (7)

NAME

NULLIFY(7f) - [FORTRAN:STATEMENT] causes pointers to be disassociated from a target

SYNOPSIS

NULLIFY ( pointer-object-list )

pointer-object is variable-name or structure-component or proc-pointer-name

DESCRIPTION

NULLIFY(3f) breaks a pointers’ association with a target. Note it is NOT used to deallocate memory -- that is the function of DEALLOCATE(3f).
In addition, since the initial association status of a pointer is undefined NULLIFY(7f) can be used to initialize an undefined pointer, giving it disassociated status ... then the pointer can be tested using the intrinsic function ASSOCIATED(3f).

MEMORY LOSS

NULLIFY IS USED TO DISCONNECT A POINTER BUT NOT DEALLOCATE TARGET

Do not use NULLIFY(3f) when you mean DEALLOCATE(3f) or you can cause memory leaks.
The inappropriate use of NULLIFY(3f) can result in large blocks of memory being left inaccessible to the program.
For instance, if you nullify a pointer that pointed to an array created with an allocate statement the memory space associated with the array becomes inaccessible to the program (unless that memory space has previously had another pointer associated with it).
All of the pointers in the following code leave memory space inaccessible when they are nullified because no other name remains by which to deallocate the memory. Hopefully, procedures may well release the memory when they go out of scope, but that is not required. Here in the main program this will almost certainly be problematic.
     program memoryloss
     implicit none
     real, pointer, dimension(:,:) :: p1,p2
     character(len=80), pointer    :: c1
     character(len=1)              :: paws
        write(*,*)’look at memory use before allocation’; read(*,*)paws
        allocate ( p1(5000,5000), c1)
        p1=1.0
        write(*,*)’look at memory use after allocation’; read(*,*)paws
        write(*,*)sum(p1)
        c1 = ’example   ’
        ! p2=>p1 ! would leave you with a way to still deallocate via "p2"
        nullify(p1,c1) ! NO!: last name to reference memory is being lost
        write(*,*)’IS P1 ASSOCIATED?’,associated(p1)
        write(*,*)’look at memory use after nullify’; read(*,*)paws
     end program memoryloss

THERE ARE TIMES WHEN YOU REALLY DO ONLY WANT TO NULLIFY AND NOT DEALLOCATE

There are times you absolutely need to use NULLIFY(3f) instead of DEALLOCATE(3f).
In the opposite case from above where the pointer merely points to a target instead of having been used in the ALLOCATE(3f) statement The nullify statement is necessary.
For example, in the next few lines of code an allocatable array called "big" is created and then the pointer p1 is set to point at this array. Later, when an attempt is made to deallocate p1, the computer

will actually try to deallocate the array big .
This should result in an error message, due to the indirect attempt at deallocation.
       program wrong_wrong_wrong
       implicit none
       real, allocatable             :: big(:,:)
       real, pointer, dimension(:,:) :: p1
          allocate(big(600,700))
          p1 => big
          deallocate (p1)  ! NO: indirect deallocation is not allowed
       end program wrong_wrong_wrong
To prevent the problems that this can cause, replace the DEALLOCATE statement with NULLIFY(3f).

OPTIONS

pointer-object-list
A pointer-object is a variable-name, structure-component, or proc-pointer-name Each pointer-object shall have the POINTER attribute (ie. it must be a pointer).
A pointer-object shall not depend on the value, bounds, or association status of another pointer-object in the same NULLIFY statement.
When a NULLIFY statement is applied to a polymorphic pointer, its dynamic type becomes the declared type.

EXAMPLE

The following is an example of the NULLIFY statement:

  real, target  :: values(0:100)
  real, pointer :: ptr_a(:), ptr_b(:)
  ptr_a => values
  ptr_b => values
  ...
  nullify(ptr_a)

At this point PTR_A will have disassociated status, but PTR_B will continue to be associated with variable VALUES().

   program demo_nullify
   implicit none
   real, pointer :: dart1 (:)
   real, pointer :: dart2 (:)
   real, allocatable, target :: island (:)

   allocate (island (7))
   island = 1.0
   island (1:7:2) = 10.0

   write (*,’(a,7f8.0)’) ’target   ’,island
   dart1 => island
   write (*,’(a,7f8.0)’) ’pointer 1’,dart1

   dart2 => dart1
   write (*,’(/a)’) merge(’dart2 is pointed    ’,&
                          ’dart2 is not pointed’,associated(dart2))
   write (*,’(a,7f8.0)’) ’pointer 2’,dart2

   nullify (dart1)
   write (*,’(/a)’) merge(’dart1 is pointed    ’,&
                          ’dart1 is not pointed’,associated(dart1))

   ! so if dart2 pointed to dart1 and dart1 is nullified can you test dart2?
   write (*,’(/a)’) merge(’dart2 is pointed    ’,&
                          ’dart2 is not pointed’,associated(dart2))

   write (*,’( a,7f8.0)’) ’pointer 2’,dart2

   end program demo_nullify

Results:

target 10. 1. 10. 1. 10. 1. 10. pointer 1 10. 1. 10. 1. 10. 1. 10.

dart2 is pointed pointer 2 10. 1. 10. 1. 10. 1. 10.

dart1 is not pointed

dart2 is pointed pointer 2 10. 1. 10. 1. 10. 1. 10.

deallocate(7f), allocate(3f), allocated(3f), associated(3f), null(3f) ################################################################################

Fortran Learner
10/4/06 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? And what is the difference among the allocate(), => and = operator for the pointer variable?

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.
Click here to Reply

Craig Powers
10/4/06 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?

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        
10/4/06
"Craig Powers" <eni...@hal-pc.org> wrote in message news:45241887$0$40072$a726171b@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

10/4/06 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?
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        
10/4/06 Craig gave seveal good answers. I’ll try to supplement what he said and add answers to some of the things that he didn’t.
Fortran Learner <ding.xi...@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        
10/4/06
"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? > Yes, as is the pointer association status. (Note: if the statement above is 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    
10/4/06 In article <45241887$0$40072$a726...@news.hal-pc.org>,
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        
10/5/06
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       
10/5/06 Hi
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        
10/5/06 Tobias Schlemmer <Tobias....@mailbox.tu-dresden.de> wrote:
> 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.
--

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
        glen herrmannsfeldt    
10/5/06 Richard E Maine <nospam@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?

> 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        
10/5/06 glen herrmannsfeldt <g...@seniti.ugcs.caltech.edu> wrote:
> Richard E Maine <nospam@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.

--

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
        glen herrmannsfeldt    
10/5/06 Richard E Maine <nospam@see.signature> wrote: > glen herrmannsfeldt <g...@seniti.ugcs.caltech.edu> wrote: >> Richard E Maine <nospam@see.signature> wrote: >> (snip on deallocate and pointers)
>> 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.

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
################################################################################

Nemo Release 3.1

nullify (7)

February 23, 2025

Generated by manServer 1.08 from 399200b4-80c6-40d4-84c6-ddd5df47dd4a using man macros.

will actually try to deallocate the array big .
	This should result in an error message, due to the indirect attempt at deallocation.

Fortran Learner
	10/4/06 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? And what is the difference among the allocate(), => and = operator for the pointer variable?

Craig Powers
	10/4/06 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?

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 10/4/06
"Craig Powers" <eni...@hal-pc.org> wrote in message news:45241887$0$40072$a726171b@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.

time through a subprogram.
	That is, unless one actually wanted to keep it between calls.
-- glen
Richard E Maine 10/4/06 Craig gave seveal good answers. I’ll try to supplement what he said and add answers to some of the things that he didn’t.
Fortran Learner <ding.xi...@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 10/4/06
"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? > Yes, as is the pointer association status. (Note: if the statement above is 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 10/4/06 In article <45241887$0$40072$a726...@news.hal-pc.org>,
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 ! ----------------------------------------

1.	as pointer
2.	as Reference to the data at the position it points to.

>	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 10/5/06 glen herrmannsfeldt <g...@seniti.ugcs.caltech.edu> wrote:
> Richard E Maine <nospam@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.
--
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
glen herrmannsfeldt 10/5/06 Richard E Maine <nospam@see.signature> wrote: > glen herrmannsfeldt <g...@seniti.ugcs.caltech.edu> wrote: >> Richard E Maine <nospam@see.signature> wrote: >> (snip on deallocate and pointers)
>> 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.
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)