Re: Pointer-valued function to access inner components

Michael Metcalf wrote:

"Walter Spector" <w6ws_xthisoutx@xxxxxxxxxxxxx> wrote in message
news:45D5C9C7.41820D64@xxxxxxxxxxxxxxxx
No, that points to a *copy* of the diagonal.

Agreed. Is this then what you meant (following Richard's hint)?

common/c/a...

Well, placing things in COMMON doesn't make them very dynamic.
But that is certainly one approach.

I was thinking more of the following:

program testdiag
implicit none

real, allocatable, target :: a(:,:)
real, pointer :: adiag(:)

integer :: i, j
integer :: n

write (*,'(a)', advance='no') 'size of matrix? '
read *, n

allocate (a(n,n))
a = 0

print *, 'A before:'
do, j=1, size (a,1)
write (*,'(100f5.2)') (a(j,i), i=1, size (a,2))
end do

adiag => getdiag (a, size (a,1))

adiag = 42.42

print *
print *, 'A after:'
do, j=1, size (a,1)
write (*,'(100f6.2)') (a(j,i), i=1, size (a,2))
end do

contains

function getdiag (t, tn)

! Return a F90 pointer which points to the diagonal of T.

integer, intent(in) :: tn
real, target :: t(tn+1,*)
real, pointer :: getdiag(:)

getdiag => t(1,:tn)

end function

end program

The above works fine, in practice, with a lot of different
compilers. I've used it with Intel, SGI IRIX, g95, gfortran,
and Salford compilers. However, it might be argued that it violates
the letter of the Standard... So one must be careful not to use it
in a situation where the compiler will potentially perform
a copyin/copyout on array A during the procedure call.

When copyin/copyout does get in the way, Cray pointers can come in
handy. Or, I presume, some of the new F2003 intrinsics. Time
will tell.

W.
.

Relevant Pages

  • Re: C programming on ARM
    ... It's a fair point that there is a difference what you can rely on for real, practical C and what the standards say. ... right shifts working as expected, division rounding as expected, char ... Aside from alignment problems (which may mean that using the pointer does not "just work", even if conversions back and forth do), ... You can't rely on these things having a consistent pointer size - you should not even rely on the C requirement of a "void *" supporting them all (embedded compilers don't always follow the standards if they conflict with generating good object code for real-world source code). ...
    (comp.arch.embedded)
  • Re: (FAQ details:) malloc(), void * and casts
    ... My understanding is that recommended practice is to not cast the ... Its like recommending that you ... Many C++ compilers have vastly superior warnings ... a pointer to any other type. ...
    (comp.lang.c)
  • Re: Total order on floating point numbers
    ... I know of who has tried out overflow trapping for C signed integers. ... I don't know if they have C compilers. ... a C pointer on either a read or write operation. ... including their size, as system dependent. ...
    (comp.arch.arithmetic)
  • Re: struct initilization via memset
    ... >>will all initialize the pointer to a null pointer. ... By the time of the first ANSI C standard, C had been around for well ... over 10 years and C compilers were developed for quite a few different ... expression with a value of 0 cast to pointer to void. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: <ctype.h> toLower()
    ... >by reference rather than returning a pointer, unless you need to return a ... >it's just called passing by reference. ... World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. ... Comeau C/C++ with Dinkumware's Libraries... ...
    (alt.comp.lang.learn.c-cpp)