Suppose I have a pointer to a polymorphic object:
TYPE, ABSTRACT:: ab
ENT TYPE
TYPE, EXTENDS(ab):: co
INTEGER:: i
ENT TYPE
Class(ab), POINTER:: foo
How do I initialize the object pointed by foo to be a co object, in the executable part of the code? I am thinking of something like
foo => co(1) ! WRONG
but this is wrong.
Pointers can only be initialized with a target with the save attribute or with null(). If you mean the initialization during compilation in the declaration part.
In the executable part of code you can certainly make the pointer to point to an object. But you need an actual object with the target attribute or you need to make an anonymous target using the allocate() statement.
co(1) is an expression or a value result of an expression. You cannot point to it, it does not have the pointer attribute. You could allocate an anonymous target with this value
allocate(foo, source=co(1))
Consider using allocatable instead of a pointer, they should be strongly preferred. If you could use allocatable, it is as simple as
foo = co(1)
thanks to the automatic (re)allocation in the assignment.
Related
I have a code that makes extensive use of a type, let say, for simplicity:
type, public :: my_type
real, allocatable, dimension(:) :: x
real, allocatable, dimension(:,:) :: coeffs
end type my_type
...
type(my_type) :: data
Later in the code, we need to write data%x and data%coeffs to a file.
Whether the user wants it or not, this file could be written in a standard unformatted binary file and recently we add the possibility to write the file in HDF5 format.
In this case, when creating the data sets for data%x or data%coeffs, I need to pass a pointer, pointing on them, as argument to some hdf5 subroutines. This pointer can be defined as follow:
f_ptr = c_loc( data%x(1) )
But to do that, I should have given the target attribute to x and coeffs in my_type definition.
My questions are then:
is it safe to give this target attribute, just in case, even if, in the end, the user does not want to use HDF5 format ?
Would it have an impact on performance ?
Would it be better to make, in the routine that writes the data, a local copy of data%x and data%coeffs to same shape arrays with the target attribute and then point at them and pass the pointer to hdf5 subroutines ?
If it helps, this code can be compiled either with gfortran or ifort.
Thanks in advance !
It is safe; maybe; there's no need to make a copy.
Typically you would pass data%x (and then data%coeffs) to a procedure that does the HDF5 dataset writing as a actual argument, say associated with a dummy array arg. If so, just give arg the TARGET attribute.
call write_array_to_hdf5_file(data%x, ...)
subroutine write_array_to_hdf5_file(arg, ...)
real, intent(in), target :: arg(:)
...
call h5d_write_f(..., c_loc(arg))
If the actual argument does not have the target attribute, then pointers associated with arg become undefined when the write_array_to_hdf5_file procedure finishes execution.
I think you have misunderstood how target works in Fortran. If I have not misunderstood you, you want to make data%x and data%coeffs targets, by giving the x and coeffs member variables the target attribute, as
type, public :: my_type
real, allocatable, dimension(:), target :: x
real, allocatable, dimension(:,:), target :: coeffs
end type my_type
type(my_type) :: data
but this is not valid syntax. To quote Intel:
The TARGET attribute can be specified in a type declaration statement or a TARGET statement
This means the target attribute can only be applied to instances of variables, not to their definitions.
And so to make data%x and data%coeffs targets, you should instead give data the target attribute, as
type, public :: my_type
real, allocatable, dimension(:) :: x
real, allocatable, dimension(:,:) :: coeffs
end type my_type
type(my_type), target :: data
This hopefully also answers your question on usage; you only need to give the target attribute to those instances of my_type which need it.
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.
In Julia am I allowed to create & use static fields? Let me explain my problem with a simplified example. Let's say we have a type:
type Foo
bar::Dict()
baz::Int
qux::Float64
function Foo(fname,baz_value,qux_value)
dict = JLD.load(fname)["dict"] # It is a simple dictionary loading from a special file
new(dict,baz_value,quz_value)
end
end
Now, As you can see, I load a dictionary from a jld file and store it into the Foo type with the other two variables baz and qux_value. Now, let's say I will create 3 Foo object type.
vars = [ Foo("mydictfile.jld",38,37.0) for i=1:3]
Here, as you can see, all of the Foo objects load the same dictionary. This is a quite big file (~10GB)and I don't want to load it many times. So,
I simply ask that, is there any way in julia so that, I load it just once and all of there 3 types can reach it? (That's way I simply use Static keyword inside the question)
For such a simple question, my approach might look like silly, but as a next step, I make this Foo type iterable and I need to use this dictionary inside the next(d::Foo, state) function.
EDIT
Actually, I've found a way right now. But I want to ask that whether this is a correct or not.
Rather than giving the file name to the FOO constructor, If I load the dictionary into a variable before creating the objects and give the same variable into all of the constructors, I guess all the constructors just create a pointer to the same dictionary rather than creating again and again. Am I right ?
So, modified version will be like that:
dict = JLD.load("mydictfile.jld")["dict"]
vars = [ Foo(dict,38,37.0) for i=1:3]
By the way,I still want to hear if I do the same thing completely inside the Foo type (I mean constructor of it)
You are making the type "too special" by adding the inner constructor. Julia provides default constructors if you do not provide an inner constructor; these just fill in the fields in an object of the new type.
So you can do something like:
immutable Foo{K,V}
bar::Dict{K,V}
baz::Int
qux::Float64
end
dict = JLD.load("mydictfile.jld")["dict"]
vars = [Foo(dict, i, i+1) for i in 1:3]
Note that it was a syntax error to include the parentheses after Dict in the type definition.
The {K,V} makes the Foo type parametric, so that you can make different kinds of Foo type, with different Dict types inside, if necessary. Even if you only use it for a single type of Dict, this will give more efficient code, since the type parameters K and V will be inferred when you create the Foo object. See the Julia manual: http://docs.julialang.org/en/release-0.5/manual/performance-tips/#avoid-fields-with-abstract-containers
So now you can try the code without even having the JLD file available (as we do not, for example):
julia> dict = Dict("a" => 1, "b" => 2)
julia> vars = [Foo(dict, i, Float64(i+1)) for i in 1:3]
3-element Array{Foo{String,Int64},1}:
Foo{String,Int64}(Dict("b"=>2,"a"=>1),1,2.0)
Foo{String,Int64}(Dict("b"=>2,"a"=>1),2,3.0)
Foo{String,Int64}(Dict("b"=>2,"a"=>1),3,4.0)
You can see that it is indeed the same dictionary (i.e. only a reference is actually stored in the type object) by modifying one of them and seeing that the others also change, i.e. that they point to the same dictionary object:
julia> vars[1].bar["c"] = 10
10
julia> vars
3-element Array{Foo{String,Int64},1}:
Foo{String,Int64}(Dict("c"=>10,"b"=>2,"a"=>1),1,2.0)
Foo{String,Int64}(Dict("c"=>10,"b"=>2,"a"=>1),2,3.0)
Foo{String,Int64}(Dict("c"=>10,"b"=>2,"a"=>1),3,4.0)
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'm trying to debug some code in which members of a user defined object mysteriously change addresses, and while doing that I realized user defined objects do that as well. Here's a small example of querying object address from function that created it and then from its member function:
module foo_module
type foo_type
contains
procedure :: foo
end type foo_type
contains
subroutine foo(this)
class(foo_type) :: this
print *, 'Inside foo this is', loc(this)
end subroutine foo
end module foo_module
program trial
use foo_module
type(foo_type) :: object
print *, 'Object address', loc(object)
call object%foo()
end program trial
A sample output I get is:
Object address 4452052800
Inside foo this is 140734643354880
Why am I getting two different addresses for the same object? Am I doing something wrong? Or is there something with LOC that comes into play I don't understand?
I'm using ifort under osx.
LOC is an extension. Its behaviour is as specified by the compiler vendor.
What the behaviour intended by the vendor here isn't clear, but the difference that you are seeing is that in the main program you get the integer equivalent of the memory address of the non-polymorphic object (what you probably expect), while in the subroutine you get the integer equivalent of the memory address of the polymorphic descriptor for the object (maybe what you want, maybe not).
Using TRANSFER(C_LOC(xxx), 0_C_INTPTR_T) is a more portable way of getting the integer representation of the address of an object (where the C_* things are from the ISO_C_BINDING intrinsic module). C_LOC requires that its argument have the TARGET attribute and be non-polymorphic (use SELECT TYPE).
I'd recommend asking on the relevant Intel Forum if you want further clarification on the intended behaviour of the LOC extension.
I reported the bug to the developers our internal issue ID is DPD200253159. I found that the C_LOC function from ISO_C_BINDING works. For example:
subroutine foo(this)
use, intrinsic :: iso_c_binding
class(foo_type) :: this
print *, 'Inside foo this is', transfer(c_loc(this),0_C_INTPTR_T)
end subroutine foo