I want to keep a deepcopy of the resulting fortran pointers from c_f_pointer for check purpose and so on.
(EDIT 1: I used 'deepcopy' as 'making a duplicate which is independent from its original'.
a = (/1,2,3,4/)
a_deepcopy = a
a_deepcopy(2) = 1
In above example, the original a remains (/1,2,3,4/) while a_deepcopy is changed to (/1,1,3,4/). If it was not a deepcopy, changing a_deepcopy's element would also change it's original a's element. I used the word 'deep copy' just becuase I've seen this kind of naming in Python context.)
program test1
use ...
use iso_c_binding
implicit none
...
type(c_ptr) :: rows_start_c, rows_end_c, col_indx_c, values_c
integer,pointer :: rows_start_f(:), rows_end_f(:), col_indx_f(:)
real*8 ,pointer :: values_f(:)
...
(*) call c_f_pointer(rows_start_c, rows_start_f, [DIM_r])
call c_f_pointer(rows_end_c , rows_end_f , [DIM_c])
call c_f_pointer(col_indx_c , col_indx_f , [rows_end_f(DIM_r)-1])
call c_f_pointer(values_c , values_f , [rows_end_f(DIM_r)-1])
...
end program test1
I've googled fairly much to find examples for the deepcopy of fortran pointer to allocatable array, which is the subject that somebody would have questioned already, but couldn't find a proper one.
The following code to copy a pointer to allocatable compiles and works fine so that deepcopy of 'pointer P' is generated in 'allocatable A2' array, but from the answers on my previous questions, I get to know that I'd better be careful treating pointer and allocatable in some mixed way even though they seems to work fine.
program pointer3
implicit none
real*8,allocatable :: A2(:)
real*8,target :: A(4)
real*8,pointer :: P(:)
A = 3.1416d0
P => A
allocate ( A2(size(A,1)) )
A2 = P # Assign 'pointer' to 'allocatable'
print *, 'Initially'
write(*,'(a, 4f6.2)') 'A ', A
write(*,'(a, 4f6.2)') 'P ', P
write(*,'(a, 4f6.2)') 'A2', A2
P(2) = 1.d0
print *, 'After'
write(*,'(a, 4f6.2)') 'A ', A
write(*,'(a, 4f6.2)') 'P ', P
write(*,'(a, 4f6.2)') 'A2', A2
end program
Initially
A 3.14 3.14 3.14 3.14
P 3.14 3.14 3.14 3.14
A2 3.14 3.14 3.14 3.14
After
A 3.14 1.00 3.14 3.14
P 3.14 1.00 3.14 3.14
A2 3.14 3.14 3.14 3.14 # A2 didn't changed after pointer modification, so a deepcopy seems to be generated
So the questions goes,
Is the above code right practice of deepcopying a pointer into a allocatable array?
If I were with ordinary fortran pointer and its target, I would try to deepcopy it to allocatable arrays just assigning its target attribute into the allocatable like below (Even though I can't do this since I'm with c_f_pointer and the equivalent target is c_ptr, which is not a fortran array).
program pointer3
implicit none
real*8,allocatable :: A2(:)
real*8,target :: A(4)
real*8,pointer :: P(:)
A = 3.1416d0
P => A
!allocate ( A2(size(A,1)) ) # Commenting this line does not induce a compile error, as well as a runtime error.
A2 = A # Assign 'target' to allocatable
print *, 'Initially'
write(*,'(a, 4f6.2)') 'A ', A
write(*,'(a, 4f6.2)') 'P ', P
write(*,'(a, 4f6.2)') 'A2', A2
P(2) = 1.d0
print *, 'After'
write(*,'(a, 4f6.2)') 'A ', A
write(*,'(a, 4f6.2)') 'P ', P
write(*,'(a, 4f6.2)') 'A2', A2
end program
This works fine as the first try of assigning a pointer right into allocatable array, but this seems weird because apparently 'A', and 'A2' differs on their type: real*8, allocatable and real*8, target.
I think both of above two methods to make deepcopy of a fortran pointer are neither proper, nor safe ones. How can I make a deepcopy of pointer in a safe, and robust way?
Thank you for reading this question.
A word of warning at the beginning: Pointers can be useful, but they are also very dangerous, in the sense that it's very easy to create very obscure and hard-to-debug mistakes with them.
I can't remember all that many cases where I honestly thought: Yes, pointers here are a good idea (though there were some).
Let's start with talking about arrays: Normal arrays have to have their shape declared at compile time, something like this:
INTEGER :: A(10)
This causes the program to set aside an area in memory to store ten integer values.
But you don't always know when coding how large the arrays actually have to be. That's why Fortran introduced allocatable arrays. Instead of declaring their shape at the beginning, the code tells the compiler that it should be prepared that memory will be needed later.
INTEGER, ALLOCATABLE :: A(:)
This tells the compiler that it will need an integer array, but it doesn't know how big it is yet. Then, when the program is running and it has figured out how large an array it needs, you can use the ALLOCATE command to actually create the memory:
ALLOCATE(A(100))
Only after you have called the ALLOCATE on the array can you actually use it. (Actually, there are more reasons to use allocatable arrays, but I won't go into the details yet.)
Pointers are different. They don't store the values, they store a memory address where the value is located. So before you can actually interact with the values, you first need to do one of two things:
Point the pointer to a target, for example:
P => A
Allocate memory that the pointer points to:
ALLOCATE(P)
You can see that also uses the ALLOCATE command, but it is used slightly differently: When you allocate an allocatable array, you associate the memory that you are allocating directly with the array. When you allocate a pointer, you allocate memory, and then write that memory's address into the memory associated with the pointer.
So with that said, let's go through what you're doing:
A is a more-or-less normal array, except that with the keyword target you've told the compiler that it should be possible to have pointers point at this array.
You set all elements of this array to a value.
P is a pointer to an array. You point P at A, which means that these two now work on exactly the same memory. Change one and the other will change as well.
Then you allocate memory for A2. A2 acts as just any other array, it has nothing to do with A or P.
Because P and A refer to the same memory, these two lines have the same effect:
A2 = A
A2 = P
In both cases, the contents of the array A are copied over to the memory of A2. Then, changing any value in A (and it doesn't matter whether you use A or P to do so) will also appear as a change in P. But the values of A2 will not be changed: They are stored somewhere else.
Thinking with pointers is really hard. When I actually have to do this, I most often sketch the process on a piece of paper beforehand, just so that I keep track on where which pointer is pointing at what time.
In Fortran, more often than not you won't need pointers. And without pointers, every copy is what you would call a 'deepcopy'.
Related
I'd like to turn a legacy Fortran code into modern Fortran compliant code, so I can turn on compiler warnings, interface checking, etc. At this stage I don't want to change the functionality, just make it work as close as possible to what it was, and still keep compilers happy.
My current problem is that the code at many places passes arrays of the wrong types, e.g. a real array to a subroutine that has an integer dummy argument. This is not a bug per se in the code, since it is intentional and it works as intended (at least in common configurations). Now, how could I do the same and while keeping the code compliant? Consider the following example:
program cast
implicit none
double precision :: a(10)
call fill_dble(a,10)
call print_dble(a,10)
call fill_int(a,10)
!call fill_int(cast_to_int(a),10)
call print_dble(a,10)
call print_int(a(1),10)
!call print_int(cast_to_int(a),10)
call print_dble(a(6),5)
contains
function cast_to_int(a) result(b)
use iso_c_binding
implicit none
double precision, target :: a(*)
integer, pointer :: b(:)
call c_f_pointer(c_loc(a(1)), b, [1])
end function
end program
subroutine fill_dble(b,n)
implicit none
integer :: n, i
double precision :: b(n)
do i = 1, n
b(i) = i
end do
end subroutine
subroutine print_dble(b,n)
implicit none
integer :: n
double precision :: b(n)
write(6,'(10es12.4)') b
end subroutine
subroutine fill_int(b,n)
implicit none
integer :: n, b(n), i
do i = 1, n
b(i) = i
end do
end subroutine
subroutine print_int(b,n)
implicit none
integer :: n, b(n)
write(6,'(10i4)') b
end subroutine
When I compile it and run it (gfortran 4.8 or ifort 18), I get, as expected:
1.0000E+00 2.0000E+00 3.0000E+00 4.0000E+00 5.0000E+00 6.0000E+00 7.0000E+00 8.0000E+00 9.0000E+00 1.0000E+01
4.2440-314 8.4880-314 1.2732-313 1.6976-313 2.1220-313 6.0000E+00 7.0000E+00 8.0000E+00 9.0000E+00 1.0000E+01
1 2 3 4 5 6 7 8 9 10
6.0000E+00 7.0000E+00 8.0000E+00 9.0000E+00 1.0000E+01
The first half of the real array is corrupted with integers (because integers are half the size), but when printed as integers the "right" values are there. But this is non-compliant code. When I try to fix it by activating the cast_to_int function (and disabling the calls without it) I get indeed something that compiles without warning, and with gfortran I get the same result. With ifort, however, I get:
1.0000E+00 2.0000E+00 3.0000E+00 4.0000E+00 5.0000E+00 6.0000E+00 7.0000E+00 8.0000E+00 9.0000E+00 1.0000E+01
1.0000E+00 2.0000E+00 3.0000E+00 4.0000E+00 5.0000E+00 6.0000E+00 7.0000E+00 8.0000E+00 9.0000E+00 1.0000E+01
0******** 0 5 6 7 8 9 10
6.0000E+00 7.0000E+00 8.0000E+00 9.0000E+00 1.0000E+01
which I can't understand. Moreover, ifort with -O0 crashes (and it doesn't with the other version).
I know the code is still not quite correct, because the pointer returned by cast_to_int is still of size 1, but I believe that should be a different problem.
What am I doing wrong, or how can I get ifort do what I want?
EDIT: Following #VladimirF's reply, I add, after implicit none:
subroutine fill_int(b,n)
!dec$ attributes no_arg_check :: b
integer :: n, b(n)
end subroutine
subroutine print_int(b,n)
!dec$ attributes no_arg_check :: b
integer :: n, b(n)
end subroutine
end interface
but compiling with warnings on still gives me an error:
$ ifort cast2.f90 -warn all
cast2.f90(17): error #6633: The type of the actual argument differs from the type of the dummy argument. [A]
call fill_int(a,10)
--------------^
cast2.f90(20): error #6633: The type of the actual argument differs from the type of the dummy argument. [A]
call print_int(a(1),10)
---------------^
compilation aborted for cast2.f90 (code 1)
Intel Fortran supports the !dec$ attributes no_arg_check directive. It instructs the compiler "that type and shape matching rules related to explicit interfaces are to be ignored".
"It can be applied to an individual dummy argument name or to the routine name, in which case the option is applied to all dummy arguments in that interface."
It should be applied to a module procedure (or an interface block), so you should move your functions and subroutines into a module.
Many other compilers have similar directives.
What is wrong about your code? As a rule of thumb, do not ever use any Fortran functions that return pointers. They are pure evil. Fortran pointers are completely different from C pointers.
When you do call fill_int(cast_to_int(a),10) what happens is that the expression cast_to_int(a) is evaluated and the result is an array. Now depending on the optimizations the compiler may choose to pass the address of the original pointer, but it may also create a copy of the result integer array and pass a copy to the subroutine.
Also, your array a does not have the target attribute, so the address used inside cast_to_int(a) is only valid inside the function and is not valid after it returns.
You should make the b inside the main program and just pass b instead of a. It will work similar to equivalence. Looking at the values stored as a different type will be not standard-conforming anyway. This form of type punning is not allowed.
I found a possible general solution that seems to work. The code I have to deal with looks something like this:
subroutine some_subroutine(a,b,c,d,...)
real a(*),b(*),c(*),d(*)
! many more declarations, including common blocks
!...
call other_subroutine(a,b(idx),c,...)
!...
end subroutine some_subroutine
! this typically in another file:
subroutine other_subroutine(x,y,z,...)
real x(*)
integer y(*)
logical z(*)
! other declarations and common blocks
! unreadable code with calls to other procedures
! not clear which which arguments are input and output
end subroutine other_subroutine
I now modify it to be:
subroutine some_subroutine(a,b,c,d,...)
real a(*),b(*),c(*),d(*)
! many more declarations, including common blocks
call inner_sub(b,c)
contains
subroutine inner_sub(b,c)
use iso_c_binding
real, target :: b(*),c(*)
integer, pointer :: ib(:)
logical, pointer :: lc(:)
!...
call c_f_pointer(c_loc(b(idx)),ib,[1]) ! or use the actual length if I can figure it out
call c_f_pointer(c_loc(c(1)),lc,[1])
call other_subroutine(a,ib,lc,...)
nullify(ib,lc)
!...
end subroutine inner_sub
end subroutine some_subroutine
leaving other_subroutine untouched. If I use directly the target attribute on the outer routine, I have to add an explicit interface to anything calling it, so instead I wrap the inner code. By using contains I don't need to pass all variables, just those that will be "punned". The c_f_pointer call should be done right before the problematic call, since index variables (idx in the example) could be in common blocks and changed in other calls, for example.
Any pitfalls, apart from those already present in the original code?
I have a problem assigning a pointer to a structure, to a pointer to a structure.
I use gfortran 4.6.3, and the name of the file is test_pointer_struct.f08 so I am using the Fortran 2008 standard (as supported by gfortran 4.6.3).
Hera comes the code:
PROGRAM test_pointer_struct
type tSmall
integer :: a
double precision :: b
end type tSmall
type tBig
integer :: h
type(tSmall), pointer :: member_small
end type tBig
type(tBig) :: var_big
type(tSmall), pointer :: var_small(:)
! We get an array of pointers to the small structure
allocate(var_small(3))
! Also allocate the member_small strucutre (not an array)
allocate(var_big%member_small)
var_big%member_small%a = 1
var_big%member_small%b = 2.0
! Now we want an element of the var_samall array of pointers, to point to the member_small in member_big
var_small(1) => var_big%member_small ! <- I get a compilation error here
! And dissasociate the member_small (we still maintain access to memory space through var_small(1)
var_big%member_small => NULL()
END PROGRAM test_pointer_struct
When I complie this, I get the following error:
Error: Se esperaba una especificación de límites para 'var_small' en (1)
Which could be translated as
Error: Limit specification expected for 'var_small' at (1)
What does this error mean?. What am I doing wrong?
Thank you very much in advance.
Fortran doesn't really do arrays of pointers. Your declaration
type(tSmall), pointer :: var_small(:)
doesn't define var_small to be an array of pointers to things of type tsmall; rather it defines it to be a pointer to an array of things of type tsmall.
When I compile your code Intel Fortran gives the rather more helpful error message
The syntax of this data pointer assignment is incorrect: either 'bound
spec' or 'bound remapping' is expected in this context.
which takes us to R735 in the Fortran 2003 standard. The compiler tries to parse var_small(1) not, as you wish, as a reference to the first element in an array of pointers but to either a bounds-spec-list or a bounds-remapping-list. The expression does not have the right syntax for either and the parse fails.
So that deals with the question of what the error means. What do you do about it ? That depends on your intentions. The usual suggestion is to define a derived type, along these lines
type myptr
type(tsmall), pointer :: psmall
end type myptr
and then use an array of those
type(myptr), dimension(:), allocatable :: ptrarray
Personally I've never liked that approach and have never needed to use it (I write very simple programs). I expect that with Fortran 2003 there are better approaches too but without knowing your intentions I hesitate to offer advice.
Generally speaking I want to rename allocatable variables in a derived type that are passed through subroutine arguments. Writing everything with 'derived%type_xx' is not so pleasant. Besides, I don't want to spend extra memory on copying the values of the derived type to a new variable which costs new allocated memory. Furthermore, I know allocatable arrays are preferred than pointers for many reasons. I try to define pointers to the allocatable variable, but failed. I tried this because I want to simplify my code, both to be readable and not to be too long. I wonder if there's a way of achieving the goal? Thanks.
Here's the demonstration code:
Module module_type
IMPLICIT NONE
TYPE type_1
REAL,ALLOCATABLE :: longname_1(:), longname_2(:)
END TYPE
END MODULE
!------------------------------------------------------------------------------------------
SUBROUTINE TEST(input)
USE MODULE module_type
IMPLICIT NONE
TYPE(type_1) :: input
input%longname_1 = input%longname_1 + input%longname_2 ! Use one line to show what I mean
END SUBROUTINE
And here's what failed:
Module module_type
IMPLICIT NONE
TYPE type_1
REAL,ALLOCATABLE :: longname_1(:), longname_2(:)
END TYPE
END MODULE
!------------------------------------------------------------------------------------------
SUBROUTINE TEST(input)
USE MODULE module_type
IMPLICIT NONE
TYPE(type_1),TARGET :: input
REAL,POINTER :: a => input%longname_1 &
& b => input%longname_2
a = a + b ! much better for reading
END SUBROUTINE
It seems like a small issue, but I'd like to read my code without too much pain in the future. So what's the best option? Thanks a lot.
You can use the ASSOCIATE construct to associate a simple name with a more complex designator or expression.
You could also use the subobjects of the derived type as actual arguments to a procedure that carried out the operation.
You pointer approach failed because you had a rank mismatch - you were attempting to associate scalar pointers with array targets. You may also have had problems if an explicit interface to your procedure was not available in the calling scope. An explicit interface is required for procedures with dummy arguments with the TARGET attribute.
Use of pointers for this sort of simple name aliasing may reduce the ability of the compiler to optimize the code. Something like ASSOCIATE should be preferred.
Update: After #IanH made his comment, I have gone back to check: I was completely and utterly wrong on why your code failed. As he pointed out in his answer, the main issue is that pointer and target have to have the same rank, so you'd have to declare a and b as:
real, pointer :: a(:), b(:)
Secondly, before you can actually point these pointers to the targets, the targets have to be allocated. Here's an example that works:
program allocatable_target
implicit none
type :: my_type
integer, allocatable :: my_array(:)
end type my_type
type(my_type), target :: dummy
integer, pointer :: a(:)
allocate(dummy%my_array(10))
a => dummy%my_array
a = 10
print *, dummy%my_array
end program allocatable_target
If you have a Fortran 2003 compatible compiler, you can use associate -- which is specifically meant for this kind of issue. Here's an example:
program associate_example
implicit none
type :: my_type
integer, allocatable :: long_name_1(:), long_name_2(:)
end type my_type
type(my_type) :: input
integer :: i
allocate(input%long_name_1(100), input%long_name_2(100))
associate (a=>input%long_name_1, b=>input%long_name_2)
a = (/ (i, i = 1, 100, 1) /)
b = (/ (2*i+4, i = 1, 100, 1) /)
a = a + b
end associate
print *, input%long_name_1
end program associate_example
Inside the associate block, you can use a and b as a shortform for the declared longer named variables.
But other than that, I suggest you get an editor with proper code completion, then long variable names are not that much of an issue any more. At the moment I'm trying out Atom and am quite happy with it. But I have used vim with the proper expansions for a long time.
I saw this question:
Fortran dynamic objects
and the accepted answer made me question if I wrote the following function safely (without allowing a memory leak)
function getValues3D(this) result(vals3D)
implicit none
type(allBCs),intent(in) :: this
real(dpn),dimension(:,:,:),pointer :: vals3D
integer,dimension(3) :: s
if (this%TF3D) then
s = shape(this%vals3D)
if (associated(this%vals3D)) then
stop "possible memory leak - p was associated"
endif
allocate(vals3D(s(1),s(2),s(3)))
vals3D = this%vals3D
else; call propertyNotAssigned('vals3D','getValues3D')
endif
end function
This warning shows up when I run my code, but shouldn't my this%vals3D be associated if it was previously (to this function) set? I'm currently running into memory errors, and they started showing up when I introduced a new module with this function in it.
Any help is greatly appreciated.
I think I wasn't specific enough. I would like to make the following class, and know how to implement the class, safely in terms of memory. That is:
module vectorField_mod
use constants_mod
implicit none
type vecField1D
private
real(dpn),dimension(:),pointer :: x
logical :: TFx = .false.
end type
contains
subroutine setX(this,x)
implicit none
type(vecField1D),intent(inout) :: this
real(dpn),dimension(:),target :: x
allocate(this%x(size(x)))
this%x = x
this%TFx = .true.
end subroutine
function getX(this) result(res)
implicit none
real(dpn),dimension(:),pointer :: res
type(vecField1D),intent(in) :: this
nullify(res)
allocate(res(size(this%x)))
if (this%TFx) then
res = this%x
endif
end function
end module
Where the following code tests this module
program testVectorField
use constants_mod
use vectorField_mod
implicit none
integer,parameter :: Nx = 150
real(dpn),parameter :: x_0 = 0.0
real(dpn),parameter :: x_N = 1.0
real(dpn),parameter :: dx = (x_N - x_0)/dble(Nx-1)
real(dpn),dimension(Nx) :: x = (/(x_0+dble(i)*dx,i=0,Nx-1)/)
real(dpn),dimension(Nx) :: f
real(dpn),dimension(:),pointer :: fp
type(vecField1D) :: f1
integer :: i
do i=1,Nx
f(i) = sin(x(i))
enddo
do i=1,10**5
call setX(f1,f) !
f = getX(f1) ! Should I use this?
fp = getX(f1) ! Or this?
fp => getX(f1) ! Or even this?
enddo
end program
Currently, I'm running on windows. When I CTR-ALT-DLT, and view performance, the "physical memory usage histery" increases with every loop iteration. This is why I assume that I have a memory leak.
So I would like to repose my question: Is this a memory leak? (The memory increases with every one of the above cases). If so, is there a way I avoid the memory leak while still using pointers? If not, then what is happening, should I be concerned and is there a way to reduce the severity of this behavior?
Sorry for the initial vague question. I hope this is more to the point.
Are you really restricted to Fortran 90? In Fortran 2003 you would use an allocatable function result for this. This is much safer. Using pointer function results, whether you have a memory leak with this code or not depends on how you reference the function, which you don't show. If you must return a pointer from a procedure, it is much safer to return it via a subroutine argument.
BUT...
This function is pointless. There's no point testing the association status of this%vals3D` after you've referenced it as the argument to SHAPE in the previous line. If the pointer component is disassocated (or has undefined pointer association status), then you are not permitted to reference it.
Further, if the pointer component is associated, all you do is call stop!
Perhaps you have transcribed the code to the question incorrectly?
If you simply delete the entire if construct starting with if (associated(this%vals3D))... then your code may make sense.
BUT...
if this%TF3D is true, then this%vals3D must be associated.
when you reference the function, you must use pointer assignment
array_ptr => getValues3D(foo)
! ^
! |
! + this little character is very important.
Forget that little character and you are using normal assignment. Syntactically valid, difficult to pick the difference when reading code and, in this case, potentially a source of memory corruption or leaks that might go undetected until the worst possible moment, in addition to the usual pitfalls of using pointers (e.g. you need to DEALLOCATE array_ptr before you reuse it or it goes out of scope). This is why functions returning pointer results are considered risky.
Your complete code shows several memory leaks. Every time you allocate something that is a POINTER - you need to pretty much guarantee that there will be a matching DEALLOCATE.
You have a loop in your test code. ALLOCATE gets called a lot - in both the setter and the getter. Where are the matching DEALLOCATE statements?
Every time setX is called, any previously allocated memory for the x component of your type will be leaked. Since you call the function 10^5 times, you will waste 100000-1 copies. If you know that the size of this%x will never change, simply check to see if a previous call had already allocated the memory by checking to see if ASSOCIATED(this%x) is true. If it is, skip the allocation and move directly to the assignment statement. If the size does change, then you will first have to deallocate the old copy before allocating new space.
Two other minor comments on setX: The TARGET attribute of the dummy argument x appears superfluous since you never take a pointer of that argument. Second, the TFx component of your type also seems superfluous since you can instead check if x is allocated.
For the function getX, why not skip the allocation completely, and merely set res => this%x? Admittedly, this will return a direct reference to the underlying data, which maybe you want to avoid.
In your loop,
do i=1,10**5
call setX(f1,f) !
f = getX(f1) ! Should I use this?
fp = getX(f1) ! Or this?
fp => getX(f1) ! Or even this?
enddo
fp => getX(f1) will allow you to obtain a pointer to the underlying x component of your type (if you adopt my change above). The other two use assignment operators and will copy data from the result of getX into either f, or (if it is previously allocated) fp. If fp is not allocated, the code will crash.
If you do not want to grant direct access to the underlying data, then I suggest that the return value of getX should be defined as an automatic array with the size determined by this%x. That is, you can write the function as
function getX(this) result(res)
implicit none
type(vecField1D),intent(in) :: this
real(dpn),dimension(size(this%x,1)) :: res
res = this%x
end function
I would like to get the address of an array pointer. The prototype codes are as following:
program main
implicit none
type foo
integer, allocatable :: i(:)
integer j
end type
type(foo) a
integer, pointer :: ai(:)
ai => a%i
print *, "The address of a is ", loc(a)
print *, "The address of a%i is", loc(ai) ! <--- I expect the same address as a.
end program main
My final target is to get the address of a with type(foo) through the address of array pointer ai, since i is the first part of type(foo).
Thanks in advance!
Li
Fortran doesn't guarantee that the first item of a user-defined the same address as that user-defined type. Maybe there is a header before the items. Maybe there is some padding. Maybe the compiler stores the items in a different order. Maybe different compilers do it differently. None of this is specified. So your expectation may not occur. There is little need in Fortran for addresses. What are you trying to do? If you are interfacing to C, the ISO_C_Binding provides C_LOC.
EDIT in response to the comment. If your goal is to simplifying the variable name by omitting the leading "a %", you can use a pointer to create an alternative variable that accesses the same storage. You don't have to try to get past the language with pointers. Example:
program main
implicit none
type foo
integer, pointer :: i(:)
integer j
end type
type(foo) a
integer, pointer :: ai(:)
allocate ( a%i (5) )
a%i = [ 2, 5, 1, 3, 9 ]
ai => a%i
write (*, '( "a%i=", 5(2X,I2) )' ) a%i
write (*, '( "ai=", 5(2X,I2) )' ) ai
end program main
Output is:
a%i= 2 5 1 3 9
ai= 2 5 1 3 9
You can't, not using standard Fortran anyway.
Note that your expectations are misplaced.
loc is an extension. What it does is processor specific, but typically it will give you an integer representation of the address of the data object that the argument represents. (The F2003 standard's C_LOC is roughly equivalent.). In this case, the data object is an allocatable array. In all processors that I am aware of the storage for that array is not in the storage for the object of derived type that hosts the allocatable component. The derived type object simply contains a descriptor that describes where the array is stored (and how big it is, etc), not storage for the array itself.