Is this standard-conforming code?
John
and another saying it isn't. Both are very knowledgeable about Fortran.
One compiler compiles with no errors, but another flags an error. Of
course, you can always move the "real :: z(t%n)" below the "type (tt) ::
t" to avoid any problem, but I am concerned about the order shown.
Thanks,
John
module test_module
implicit none
type tt
integer :: n
end type tt
contains
!==========================
subroutine test_sub_1(z,t)
implicit none
real :: z(t%n)
type (tt) :: t
end subroutine test_sub_1
!==========================
end module test_module
Craig Dedo
> Is the below code standard conforming? I have one group saying it is and
> another saying it isn't. Both are very knowledgeable about Fortran. One
> compiler compiles with no errors, but another flags an error. Of course, you
> can always move the "real :: z(t%n)" below the "type (tt) :: t" to avoid any
> problem, but I am concerned about the order shown.
>
> Thanks,
> John
No, it is not standard conforming. Using the name of a derived type before
it is defined explicitly violates the rules in section 5.1.1.1 of Fortran 2003.
Here is the relevant text:
[Begin quote]
5.1.1.1 TYPE
A TYPE specifier is used to declare entities of a derived type.
Where a data entity id declared explicitly using the TYPE specifier, the derived
type shall have been defined previously in the scoping unit or be accessible
there by use or host association.
[End of quote]
There is an exception later in the paragraph for function results.
> module test_module
> implicit none
>
> type tt
> integer :: n
> end type tt
>
> contains
> !==========================
> subroutine test_sub_1(z,t)
> implicit none
>
> real :: z(t%n)
> type (tt) :: t
>
> end subroutine test_sub_1
> !==========================
> end module test_module
--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>
Michael Metcalf
> another saying it isn't. Both are very knowledgeable about Fortran. One
> compiler compiles with no errors, but another flags an error. Of course,
> you can always move the "real :: z(t%n)" below the "type (tt) :: t" to
> avoid any problem, but I am concerned about the order shown.
>
must have its type specified earlier in the sequence ("Fortran 95/2003
Explained", Section 7.14).
Regards,
Mike Metcalf
Richard Maine
> "John" <gh1...@yahoo.com> wrote in message
> news:fu4ru9$dbi$1...@aioe.org...
> > Is the below code standard conforming?..
> No, it is not standard conforming. Using the name of a derived type
> before it is defined explicitly violates the rules in section 5.1.1.1 of
> Fortran 2003.
While I agree that the code is illegal, this isn't the reason. See
Michael's post for the relevant citation.
The code in question does not use the name of a derived type before it
is defined. The name of the derived type is "acessible there by use or
host association", which your citation specifically says is ok. The code
uses the name of a *VARIABLE* before that variable is defined, which is
a diferent thing. The variable happens to be of derived type, but that's
not directly relevant to the problem.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Craig Dedo
news:1ifhe06.1tbdnqwxbkkN%nos...@see.signature...
Oops. My bad. Thanks for the correction.
glen herrmannsfeldt
> No, it is not standard conforming. Using the name of a derived type
> before it is defined explicitly violates the rules in section 5.1.1.1 of
> Fortran 2003. Here is the relevant text:
> [Begin quote]
> 5.1.1.1 TYPE
> A TYPE specifier is used to declare entities of a derived type.
> Where a data entity id declared explicitly using the TYPE specifier, the
> derived type shall have been defined previously in the scoping unit or
> be accessible there by use or host association.
> [End of quote]
> There is an exception later in the paragraph for function results.
There should also be an exception for pointers, such that a derived
type can contain pointers to itself. I don't see that in 5.1.1.1, though.
-- glen
Dick Hendrickson
general rules for types. Chapter 5 gives the rules for declaring
objects of a type.
Dick Hendrickson
John
John