I have seen some comments that using pointers in Fortran is considered a bad habit.
I have used Fotran since 1977 and when I started writen a large software package in 2012 I found pointers and other features of F90 an extremely useful for my data structuring. In my thermodynamics code I do not have any large matrices, insted there are many lists with variable sizes and strong interconnectivity simply arranged by pointers.
Computational times are not very critical except for simulations but then the thermodynamic part is not really the time critical part.
Pointers can result in memory leaks, they can point to deallocated memory areas, and other possible troublesome. But, there are cases where they are helpful.
Ground rule: prefer allocatable to pointer whenever possible, but don’t be shy using pointers where they make life easier.
Pointers in Fortran are much better behaved than in a language like C. They are not merely addresses. That said, @PierU 's ground rule is well worth adhering to.
Although you said performance wasn’t an issue with your code, it is with most other folks. Since pointers are a form of aliasing, it makes it difficult for the compiler to vectorize loops that make heavy use of pointers. The compiler can’t assume the arrays being accessed are contiguous in memory and proceed as if they had a unit stride. The CONTIGUOUS attribute is suppose to help with that but I’ve seen no evidence that it actually does in most compilers.
The thermodynamic model for each phase (sometimes more than 100 phases) is very varied with sometimes several sublattices with 10-20 constituents on each and model parameters which depend on a complex way on the different constituent fractions. I allocate for each phase the appropriate structure to store the data but the minimizer calculating the Gibbs energy of the phases mainly use pointers to access this data. The minimizer calculated values of G and first and second derivatives with respect to T, P and the fractions and store this in some matrices for the numerical routines for find the minimum. This is very flexible and I find it diffucult to imagine a better way. I assume the use of associated(pointer) is a reasonable secority to find pointers to nowhere.
The difficulty is not so much pointers that have not been associated, but pointers that point to memory that has been released. The attached little program had this output (results may vary):
P associated? T
Q associated? T
Q associated to P? T
Freeing the memory ...
Q associated? F
P associated? T
Values of P:
0 1818717765 1600680809 1953066581 1260414053 1684500073 825126255 3290418 0 0
When I uncomment the print statement, things are as expected.
The problem is that I allocate the memory via the pointer p and then deallocate it via the pointer q. The compiler cannot (or perhaps simply does not) track the interdependency. This type of problems cannot occur with allocatables, as there is no aliasing of this type. dangling_pointer.f90 (711 Bytes)
I used the gfortran compiler on Windows for this and to see the weird numbers appear you may have to run the program several times, as sometimes the output looks correct.
Agreed with @PierU. Also some compilers allow you to detect such leaks and dangling pointers, for example:
program test
real, pointer :: A(:)
allocate(A(3))
print *, A
!deallocate(A)
end program
This prints:
$ lfortran a.f90 --detect-leaks
0.00000000 0.00000000 0.00000000
---------------- Memory Leak Report ----------------
==> LEAK: 12 bytes
----------------------------------------------------
----------------------------------------------------
TOTAL LEAKS FOUND : 1, 12 bytes total
----------------------------------------------------
We need to make it more useful to print the line number that allocated it, etc. But it’s a start. The NAG compiler can diagnose some dangling pointers I believe.
My plan is to make LFortran by default to catch all pointers issues (dangling and leaks). That way you’ll get nice runtime error messages for all pointer issues.
But even better is to just us allocatable, then things can’t leak (in all compilers) or segfault (this depends on the compiler), e.g.:
program test
real, allocatable :: A(:)
print *, A
end program
This gives:
$ lfortran a.f90
runtime error: Argument 1 is unallocated.
--> a.f90:3:10
|
3 | print *, A
| ^ This is unallocated
I personally never use pointers, as I find there are alternatives that I am more comfortable with, such as allocatable.
But that being said, if you are confident with using pointers and can manage their issues ( loss of focus/memory leaks) they can be a useful addition to the coding problems you have.
The other issue we all face is maintainability, which is not just limited to pointers in Fortran.
One can also mix allocatables and pointers. For example, you can make a linked list that goes forward with allocatables and backwards with pointers. Another example, if a rank-2 allocatable has the target attribute, then you can have rank-1 pointers associated with individual rows and/or columns.
I do not think I allocate pointer variables, I use pointers to data that should be allocated already. The allocations are made when I enter the data, then my routine to calculate Gibbs energies and derivatives use pointers to these data, which are spread over the whole data structures, in order to multiply with the current set of T, P and constition variables. At least that is my concept how my program should work, maybe there are gliches here and there.
I’ve found this (and the default array-bounds-checking in debug mode) to be among the most useful features of LFortran, even at this early stage. I had to wonder why other compilers don’t do similar checks or error reporting.
Another helpful thing, that would aid with debugging, would be to print out a stack trace in case of a program crash due to a segmentation fault – similar to how ifx does it.
I have a single program where I used pointers in decades of F90, and hundreds of libraries and programs using ALLOCATABLE. Occasionally there is a place where it jumps off the paper as a solution, but it seems pretty rare for me.