Deallocating derived type field

[ender01]

Hello all,

I've an object Foo:

[cpp]type foo
   integer(kind=I_LO) :: size
   character(len=1), dimension(:), allocatable :: fooVar
end type foo[/cpp]

I instantiated an object of type foo via the default constructor

[cpp]character(len=1), dimension(1) :: testArray
type(foo) :: testFoo
...

testFoo = foo(1,testArray)

...[/cpp]

Later I wish to clear testFoo:

[cpp]testFoo%size = 0
deallocate(testFoo%fooVar)[/cpp]

When execution hits the deallocate statement I get an error:

severe (173): A pointer passed to DEALLOCATE points to an array that cannot be deallocated

Is there a way to free the memory?

Thanks,

Rich

[Paul_Curtis]

The error message is consistent with the fact that testarray has not been defined as allocatable. Make testarray allocatable and allocate it before associating it with the derived type, and subsequent deallocates will work.

Why should instantiating a derived type include an implicit allocate if the derived type has an allocatable component? I think you would always need an explicit allocation of such a component.

[ender01]

Quoting - Paul Curtis

The error message is consistent with the fact that testarray has not been defined as allocatable. Make testarray allocatable and allocate it before associating it with the derived type, and subsequent deallocates will work.

Why should instantiating a derived type include an implicit allocate if the derived type has an allocatable component? I think you would always need an explicit allocation of such a component.

Thanks Paul, but that doesn't really answer the underlying question, it just kicks the can down the road. To answer your question, "Why should instantiating a derived type include an implicit allocate if the derived type has an allocatable component?" Because it's part of the Fortran 2003 standard.

[Steven_L_Intel1 · Accepted solution]

Quoting - ender01

Thanks Paul, but that doesn't really answer the underlying question, it just kicks the can down the road. To answer your question, "Why should instantiating a derived type include an implicit allocate if the derived type has an allocatable component?" Because it's part of the Fortran 2003 standard.

What you're actually doing is assigning to a derived type with an allocatable component - I would not call this "instantiating". You are correct that F2003 says this will allocate the components, however that is not enabled by default in Intel Fortran. You need /assume:realloc_lhs to get that.

[ender01]

Quoting - Steve Lionel (Intel)

What you're actually doing is assigning to a derived type with an allocatable component - I would not call this "instantiating". You are correct that F2003 says this will allocate the components, however that is not enabled by default in Intel Fortran. You need /assume:realloc_lhs to get that.

Thanks Steve! I would however argue that what I am doing is indeed instantiating an object of type foo though I think that the difference is largely semantic. I am using the OO features of Fortran 2003 and applying the OO paradigm to design and build the code. Within that framework, I am instantiating and manipulating ojects. If Fortran is going to support OO that is the proper way to look at it.

Thanks again,

Rich