Link Copied
Consider the following silly code:
type :: a_t
integer, allocatable :: x(:)
end type
type :: b_t
type(a_t) :: a(2)
end type
type :: c_t
type(b_t) :: b
end type
type(c_t) :: c
allocate( c%b%a(1)%x(2), source=1 )
allocate( c%b%a(2)%x(3), source=2 )
print *, c%b%a(1)%x(1)
print *, c%b%a(2)%x(2)
end Upon building and execution, it works as expected:
1
2
Press any key to continue . . .However, if one places a breakpoint at the line 13 during a debugger session in Visual Studio and views the object, the "Undefined pointer/array" info will be noticed:
This has nothing to do with the specific Fortran code, rather it is a gap/limitation of the Intel Fortran integration with Visual Studio.
This is an issue which has long been present in form or other, at least for 10 years or more. Yet Intel Software team has NOT been able to bring sufficient attention and resources to resolve this problem.
It's beyond shameful.
But there is nothing the customers can do other than use "tricks": one such option - not that I always recommend it - is to use ASSOCIATE construct with temporary code used for debugging. For example,
I thank you for the kind and quick reply, you were very helfpful, even if unfortunately the proposed solution can only be a work-around of the problem.
In that case, I would prefer the use of ALLOCATABLE: type(a_t), ALLOCATABLE :: a(:)
type :: a_t
integer, allocatable :: x(:)
end type
type :: b_t
type(a_t) :: a(2)
type(a_t), ALLOCATABLE :: aa(:) ! => this is fine for VS
end type
type :: c_t
type(b_t) :: b
end type
type(c_t) :: c
allocate( c%b%a(1)%x(2), source=1)
allocate( c%b%a(2)%x(3), source=2)
ALLOCATE(c%b%aa(2))
allocate( c%b%aa(1)%x(2), source=1)
allocate( c%b%aa(2)%x(3), source=2)
print *, c%b%a(1)%x(:)
print *, c%b%a(2)%x(:)
print *, "--------------------------"
print *, c%b%aa(1)%x(:)
print *, c%b%aa(2)%x(:)
end In this way we don't need to use the ASSOCIATE construct to do debugging (in general I never use prints, this was just to look at the real bahaviour of the code).
