Prev: Update: Strange behaviour (CVF)
Next: Best References for Fortran 2003?
From: blitheli on 13 Apr 2008 00:23
the source code is below, I am confused with that, if we
deallocate(phead), why ptail is still associated? I found that ptail
%ip is still 2;
Can anyone explains this for me?
Thanks!
!-------------------------------------------------------------
module testtype
implicit none
public

type :: tp
sequence
integer :: ip=0
type(tp), pointer :: next => null()
end type tp

subroutine sub
use testtype
implicit none
type(tp),pointer:: phead=>null(),ptail=>null()

allocate(phead)
ptail=>phead

phead%ip=1

allocate(ptail%next)
ptail=> ptail%next
ptail%ip=2

deallocate(phead)

end subroutine sub

From: Richard Maine on 13 Apr 2008 01:47
blitheli <blitheli(a)gmail.com> wrote:

> the source code is below, I am confused with that, if we
> deallocate(phead), why ptail is still associated? I found that ptail
> %ip is still 2;
[code elided]

Actually, ptail is not associated. When you deallocate phead, the
association status of any pointers to it becomes undefined. That's
standard-speak for "don't touch them; don't even try to look; if you do
so,all bets are off."

Any subsequent reference to ptail is invalid, but not in a way that a
compiler is required to check. It is completely your reponsability.
(Yes, pointers are error-prone.)

Note that you aren't even allowed to use the associated intrinsic on a
pointer whose association status is undefined. If you do so, it may well
return a bogus result, but it isn't meaningful. The associated intrinsic
can distinguish between pointers that are associated or disasociated,
but only if you have ruled out the possibility of undefined associatiuon
status. There is no way to test for undefined association status; you
just have to know.

Under the hood, what has probably happened in your case is that ptail
still is pointing to the memory where phead used to be. That memory
hasn't yet been used for something else, so it appears to be ok. But it
isn't. Other things might later use the memory.

That was the long version. The short version is that the code is illegal
(because it references an undefined pointer) so anything can happen;
there are no guarantees.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
From: Richard L Walker on 13 Apr 2008 02:48
Pointers are why I went from C back to FORTRAN. I could write a
program in FORTRAN in less than an hour. It might take me all day
with C given all the complexities and errors I was going to make. C
is more powerful? C is closer to the machine? Sure. If you're just
solving problems and already know the relatively old FORTRAN, I'd just
stick with it. Pointers? Egad.

I'm confused with what appears to be an effort to turn FORTRAN into C.
Am I misreading this?
From: glen herrmannsfeldt on 13 Apr 2008 04:19
Richard L Walker wrote:

> Pointers are why I went from C back to FORTRAN. I could write a
> program in FORTRAN in less than an hour. It might take me all day
> with C given all the complexities and errors I was going to make. C
> is more powerful? C is closer to the machine? Sure. If you're just
> solving problems and already know the relatively old FORTRAN, I'd just
> stick with it. Pointers? Egad.

> I'm confused with what appears to be an effort to turn FORTRAN into C.
> Am I misreading this?

Fortran pointers are different from C pointers. Is that enough?
Many of the things that C lets you do with pointers you can't do
with Fortran pointers.

-- glen

From: Richard Maine on 13 Apr 2008 04:46
Richard L Walker <rlwalker(a)granis.net> wrote:

> I'm confused with what appears to be an effort to turn FORTRAN into C.
> Am I misreading this?

In short, yes, you are misreading it.

In somewhat longer, Fortran borrows ideas from many languages. Some are
from C. Some are from other languages. Fortran pointers, in particular,
are not at all like C pointers. I don't actually know why anyone would
particularly think Fortran pointers were from C unless one didn't know
much in the way of other languages. Many (I'm tempted to say "most")
languages have some form of pointer. Why do you pick on C in particular?
While I'm not a Java programmer myself, I've been told that Fortran
pointers have at least some simillarity to Java reference types (I might
not have the term quite right).

Pointers were added to Fortran for the "obvious" reason - that they make
some things a lot easier to do - not because of some peculiar desire to
"turn Fortran into C". That would indeed be a peculiar desire. I'm not
quite sure why anyone would want such a peculiar thing. It sure doesn't
sound like any of the people who I knew on the committee.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
 |  Next  |  Last
Pages: 1 2
Prev: Update: Strange behaviour (CVF)
Next: Best References for Fortran 2003?