Prev: Formatted stream I/O
Next: multi-threaded FFTW segmentation fault with gfortran
From: Richard Maine on 4 Dec 2007 13:08
James Van Buskirk <not_valid(a)comcast.net> wrote:

> "Richard Maine" <nospam(a)see.signature> wrote in message
> news:1i8l7w2.1ciwl9j13dmg4uN%nospam(a)see.signature...
>
> > For Cray pointers in interface blocks, the syntax should pretty much
> > document that you can't use Cray pointers there because they don't fit
> > in the syntax. The only things you can have in an interface block in
> > f90/f95 are interface bodies and module procedure statements. Cray
> > pointers aren't either of those. (F2003 also allows procedure
> > statements, which is at least a little easier to see as potentially
> > fitting).
> [example code]

Oh. I see... well sort of. Actually I pretty much always have trouble
reading Cray pointer code, and this is no exception; Cray pointer syntax
doesn't mesh with my intuition. But anyway, I see that what you have in
the interface block is just an ordinary interface body, so that does at
least match the syntax of an interface block.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
From: James Van Buskirk on 4 Dec 2007 15:18
"Richard Maine" <nospam(a)see.signature> wrote in message
news:1i8ld6n.1jn6gesdpj465N%nospam(a)see.signature...

> Oh. I see... well sort of. Actually I pretty much always have trouble
> reading Cray pointer code, and this is no exception; Cray pointer syntax
> doesn't mesh with my intuition. But anyway, I see that what you have in
> the interface block is just an ordinary interface body, so that does at
> least match the syntax of an interface block.

So do you find this more readable?

C:\g95\test>type alloc_pp.f90
! File: alloc_pp.f90
! Public domain 2007 James Van Buskirk
module mod1
implicit none
abstract interface
subroutine can_alloc(x)
implicit none
integer, allocatable :: x(:)
end subroutine can_alloc
end interface
procedure(can_alloc), pointer, save :: ptr
interface zarp
procedure ptr
end interface zarp
end module mod1

module mod2
implicit none
integer N
contains
subroutine alloc_me(x)
integer, allocatable :: x(:)

allocate(x(N))
end subroutine alloc_me
subroutine dealloc_me(x)
integer, allocatable :: x(:)

deallocate(x)
end subroutine dealloc_me
end module mod2

program test
use mod1
use mod2
integer i
integer, allocatable :: x(:)

N = 10
ptr => alloc_me
call zarp(x)
x = [(2*i-1, i = 1, size(x))]
do i = 1, size(x)
write(*,'(2(a,i0))') 'x(',i,') = ',x(i)
end do
ptr => dealloc_me
write(*,*) allocated(x)
call zarp(x)
write(*,*) allocated(x)
end program test
! End of file: alloc_pp.f90

C:\g95\test>g95 -std=f2003 -Wall alloc_pp.f90 -oalloc_pp
In file alloc_pp.f90:13

procedure ptr
1
Error: Unclassifiable statement at (1)

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


From: Richard Maine on 4 Dec 2007 16:32
James Van Buskirk <not_valid(a)comcast.net> wrote:

> "Richard Maine" <nospam(a)see.signature> wrote in message
> news:1i8ld6n.1jn6gesdpj465N%nospam(a)see.signature...
>
> > Oh. I see... well sort of. Actually I pretty much always have trouble
> > reading Cray pointer code, and this is no exception; Cray pointer syntax
> > doesn't mesh with my intuition. But anyway, I see that what you have in
> > the interface block is just an ordinary interface body, so that does at
> > least match the syntax of an interface block.
>
> So do you find this more readable?

[example with procedure pointers instead of Cray procedure pointers]

Yes. Mostly bcause I can tell what is pointing at what. The Cray pointer
stuff always leaves me confused about that. It strikes me as more
simillar to a funny kind of equivalence, in that I allocate space to one
name and then I reference it by some other name, with the two names
having been connected by the Cray pointer statement.

I tend to get confused about which of the two names of the Cray pointer
I use in what contexts.

In your case, both versions are a bit hard for me because the generic
just adds an extra layer of naming indirection. So even the F2003
procedure pointer version assignes the pointer target and then
references it by another name (th egeneric name). I don't see that the
generic does anything useful here. I suppose this might be an extract
from a larger sample where there were also other things in the generic.

But in the Cray pointer version has a second level of naming indirection
in addition to the generic one.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
First  |  Prev  | 
Pages: 1 2
Prev: Formatted stream I/O
Next: multi-threaded FFTW segmentation fault with gfortran