What is the different between allocatable and pointer variable?

What is the different between allocatable and pointer variable?

What is the different between allocatable and pointer variable?

integer, allocatable :: i
integer, allocatable, dimension(:) :: i
integer, allocatable, dimension(:,:) :: i

I can use pointer to do the same thing of the above examples. no matter a variable is allocatable or pointer, thay both should be deallocated. so I don't know the difference between them, and which one should i choose under certain circumstance.

I appreciate your help!

publicaciones de 11 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

An allocatable variable without TARGET attribute, when allocated, identifies a region of memory that is NOT referenced by a POINTER (it may be referenced by a DUMMY argument).

An allocatable variable with TARGET attribute, when allocated, identifies a region of memory that may be referenced by a POINTER.

A POINTER variable can be allocated or point to an allocatable with TARGET attribute.

The distinction is not of significance until one considers optimization considerations.

Allocatable without TARGET cannot be aliased (except via DUMMY arguments)
Allocatable with TARGET may be aliased (by other variable with POINTER)
POINTER may be aliased (or may stand alone)

Code that potentially may be aliased (multiple non-DUMMY references to same memory or overlapping memory) has different requirements to follow to assure proper execution of code. This will effect what code to generate with respece to SIMD vectors and copy operations (do you copy from front to back or back to front or make temp copy then copy front to back, can copy use SIMD vectors or byte-by-byte, etc...)

Jim Dempsey

www.quickthreadprogramming.com

Other differences - an ALLOCATABLE variable is always contiguous and therefore may participate in sequence association - a pointer variable may not. Intrinsic assignment to an allocatable array automatically reallocates it to match the expression on the right side (requires /standard-semantics), pointer arrays don't do this. Local allocatable variables are automatically deallocated on routine exit (unless SAVEd), not so for pointers.

I recommend using allocatable variables instead of pointers unless you need to use pointer assignment.

Steve - Intel Developer Support

Thanks Steve!

type(testype), pointer, dimension(:) :: pt
allocate(pt(10))

type(testype), target, dimension(10) :: t
type(testype), pointer, dimension(:) :: ptr
ptr => t

I think if I allocate memeory directly to a pointer, the variable must be contiguous, like the first example. However, if I use the pointer pointe to a object array, because the array may not be contiguous, so when use the pointer, it is not contiguous.

The seccond, you metioned "Intrinsic assignment to an allocatable array automatically reallocates it to match the expression on the right side (requires /standard-semantics), pointer arrays don't do this." I cann't comprehend this, can you give me a simple example? Thank you very much!

Here's a very simple example:

integer, allocatable :: a(:)
a = [1,2,3]
print *, a
a = [4,5,6,7,8]
print *, a
end

If you build with /standard-semantics, you get:

 1 2 3
 4 5 6 7 8

Note that there is no ALLOCATE of the array. On the first assignment, it notices that A is not allocated so it allocates it to the shape of the expression on the right (three elements) then does the assignment. On the second assignment it notices that A is allocated but the shape doesn't match, so it gets deallocated and reallocated automatically. You don't get this with pointers.

Also, you are correct that an initial allocation of a pointer is contiguous, but the compiler can't count on that since the pointer can get reassigned at any time to a non-contiguous slice.

Steve - Intel Developer Support

Steve,

I have not used allocatable arrays, so haven't any experience.  In your example of the automatic deallocation and reallocation of an array - does this flag a compile time warning?  Your example could occur if the second array name was misspelt, and so the reallocation not intended.

Thanks

David

Thank you very much, Steve!

Quote:

David White wrote:

Steve,

I have not used allocatable arrays, so haven't any experience.  In your example of the automatic deallocation and reallocation of an array - does this flag a compile time warning?  Your example could occur if the second array name was misspelt, and so the reallocation not intended.

Is your concern if `a` on the left hand side of the second assignment statement was misspelt?  I can't see how allocatable reallocation is anything special here.  If `a` wasn't allocatable and you misspelled it to a similarly named, already declared, rank one variable you'd be in just as much pain from a program logic point of view.

Ian,

I was thinking along the lines that if you attempted to assign the incorrect number of elements to an ordinary array because you had misspelled the array name, then it is likely that the compiler will warn that not all elements are assigned, etc.  In the case of the allocatable array, this would appear to happen silently, and I was assuming that then having a different size array to what was expected could have other, more serious consequences, in addition to the fact that the array now had the wrong data.

Regards,

David

If you knew the array size at compile time, then in most cases the array wouldn't need to be allocatable. If it is allocatable, then that's often because the size is not known till runtime, which excludes the possibility of compile time checks in the general case. 

For a non-allocatable array the compiler could generate code for runtime shape checking as part of a debug build, but note that ifort (at least last time I checked) does not do such checks (though this would be a nice feature). 

If you want to suppress the possibility of reallocation of an allocatable, you can always make the left hand side of an assignment statement an array section (append (:) to the rank one array and similar for higher ranks).

If an allocatable array did happen to be allocated to the wrong size due to some programming mistake or input error, then practically at some stage you would be doing something with its misshaped value.  If the compiler actually had runtime shape checking in addition to its existing bounds checking capaibility, then it would likely trap the error at that point.  I could invent potential exceptions - perhaps where the array was allocated to a larger shape than intended and then the excess elements were never referenced and hence the program never became non-conforming - but the practical likelihood of those exceptions strikes me as small.

There has been some concern that the possibility for reallocation might present some overhead in the case where the programmer knows that the shapes of the right hand side will always match the left hand side, but I'd be surprised if it mattered in the vast majority of use cases; and the workaround in the event that it does matter is trivial.

Reallocation is now part of the language and, from my point of view, rather useful, particularly when combined with the deferred length character concept.  Consequently, a warning message for every assignment to an allocatable would be intolerable noise.

The automatic reallocation is required by the Fortran 2003 standard. We don't do this by default for compatibility with Fortran 90 programs as the added checking is time-consuming. If you don't want the automatic reallocation, don't use /standard-semantics (or /assume:realloc_lhs), but then if you make a mistake you may or may not get a runtime error.

Steve - Intel Developer Support

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya