allocatable initialization
egio
I can compile, link and run the following program with gfortran 4.6
snapshot 20110129:
program scalarallocation
type test
real :: a
end type
class (test), allocatable :: b = test(3.4)
print *,'B', allocated(b)
end program
I'd like to know if the initialization of the allocatable variable "b"
is FORTRAN standard. I don't have other f2003/2008 compilers at the
moment, so I cannot cross check with other compilers. By the way, if I
substitute "class" with "type" the compiler correctly complains.
Thank in advance,
Edmondo
Tobias Burnus
> I can compile, link and run the following program with gfortran 4.6
> snapshot 20110129:
> class (test), allocatable :: b = test(3.4)
>
> I'd like to know if the initialization of the allocatable variable "b"
> is FORTRAN standard.
It is not; quoting the F2008 standard:
"C506 (R503) An initialization shall not appear if object-name is a
dummy argument, a function result, an object in a named common block
unless the type declaration is in a block data program unit, an object
in blank common, an allocatable variable, or an automatic object."
I filled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47572
> By the way, if I substitute "class" with "type" the compiler
> correctly complains.
I think the problem is the way polymorphic variables ("CLASS") are
handled internally, which causes that some check that work for
nonpolymorphic variables do not work properly for polymorphic variables.
Tobias
egio
it to:
class(test), allocatable :: b
allocate(b , source= test(3.4))
that, I think, should be standard FORTRAN now.
In both cases valgrind (version 3.5) gave no memory leaks. But in the
previous (non standard) case gave 16 allocated and freed blocks, while
in the second case gave 17 allocated and freed blocks.
Edmondo
Richard Maine
[about initialization of an allocatable]
> It is a pity, it would have been a nice feature.
I agree. In fact I think it a bit anomalous that you aren't even allowed
to use initialization syntax to confirm the way that allocatables act by
default in some cases. In particular, an allocatable component acts as
though it had a default initialization to uninitialized. I can't think
of any cases where you can distinguish between what an alocatabl
component does and what a default initialization to uninitialized would
do. But it isn't called default initialization in the case of an
allocatable component, and you aren't allowed to use the syntax of
default initialization even confirm the same behavior, possibly to make
it more evident to the reader.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Tobias Burnus
> I agree. In fact I think it a bit anomalous that you aren't even allowed
> to use initialization syntax to confirm the way that allocatables act by
> default in some cases. In particular, an allocatable component acts as
> though it had a default initialization to uninitialized. I can't think
> of any cases where you can distinguish between what an alocatabl
> component does and what a default initialization to uninitialized would
> do. But it isn't called default initialization in the case of an
> allocatable component, and you aren't allowed to use the syntax of
> default initialization even confirm the same behavior, possibly to make
> it more evident to the reader.
Reading your comment, I was reminded of a vaguely related feature in
Fortran 2008, which allows one to deal better with allocatable
components: "A structure constructor can omit the value for an
allocatable component." (F2008, introduction), namely:
"C492 (R455) A component-spec shall be provided for a nonallocatable
component unless it has default initialization or is inheritance
associated with a subcomponent of another component for which a
component-spec is provided."
Tobias
Richard Maine
Hmm. I didn't recall that change. Sounds almost more like a defect fix,
but I guess it wasn't treated that way. I might have preferred to make
the change the other way - that is to either say that what already
happens to allocatable components is a case of default initialization
(just like it acts), or at least to say that you could explicitly
specify at least null default initialization for an allocatable
component. Then the newly added exception would not have been needed.