Fortran Programming Language :: INTENT(IN) for user defined type effect for pointer members?


	INTENT(IN) for user defined type effect for pointer members? ! Suppose I have a user defined type with a pointer member: TYPE FOO_T INTEGER, POINTER :: IA(:) END TYPE FOO_T ! And then a subroutine SUBROUTINE BAR(FOO) TYPE(FOO_T), INTENT(IN) :: FOO ! Can I then write to the contents of FOO%IA(:) ? FOO%IA(:) = 0 ! Is this legal? ! Intels ifort accepts this code, but is this correct? END SUBROUTINE BAR On Apr 27, 11:36 am, Oskar Enoksson <nob@nowhere.org> wrote: > ! Suppose I have a user defined type with a pointer member: > TYPE FOO_T > INTEGER, POINTER :: IA(:) > END TYPE FOO_T ... > SUBROUTINE BAR(FOO) > TYPE(FOO_T), INTENT(IN) :: FOO > ! Can I then write to the contents of FOO%IA(:) ? > FOO%IA(:) = 0 ! Is this legal? ... > END SUBROUTINE BAR It's OK. In fact, as of F2003, pointers themselves may have INTENT(IN). It means the pointer can't change but its target can. I more often need the reverse, but there's no way to declare that. It's a danger since neither should be allowed to change within a PURE procedure. Altering a target of a pointer argument is a side-effect that pretty much destroys the main purpose of the PURE attribute. I think (but don't have the document now to look it up) that there are some prohibitions in the case of PURE procedures, but I vaguely remember some case that slipped throught the cracks. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare Ok thanks for responding. Wouldn't it have been more natural to protect both the pointer itself and elements pointed to for INTENT(IN) pointers? /Oskar - Hide quoted text - jamesgi@att.net wrote: > On Apr 27, 11:36 am, Oskar Enoksson <nob@nowhere.org> wrote: >> ! Suppose I have a user defined type with a pointer member: >> TYPE FOO_T >> INTEGER, POINTER :: IA(:) >> END TYPE FOO_T > ... >> SUBROUTINE BAR(FOO) >> TYPE(FOO_T), INTENT(IN) :: FOO >> ! Can I then write to the contents of FOO%IA(:) ? >> FOO%IA(:) = 0 ! Is this legal? > ... >> END SUBROUTINE BAR > It's OK. In fact, as of F2003, pointers themselves may have > INTENT(IN). It means the pointer can't change but its target > can. I more often need the reverse, but there's no way to > declare that. > It's a danger since neither should be allowed to change within > a PURE procedure. Altering a target of a pointer argument is > a side-effect that pretty much destroys the main purpose of > the PURE attribute. I think (but don't have the document now > to look it up) that there are some prohibitions in the case of > PURE procedures, but I vaguely remember some case that slipped > throught the cracks. > -- > J. Giles > "I conclude that there are two ways of constructing a software > design: One way is to make it so simple that there are obviously > no deficiencies and the other way is to make it so complicated > that there are no obvious deficiencies." -- C. A. R. Hoare "Oskar Enoksson" <nob@nowhere.org> wrote in message news:f0tebl$fpu$1@news.lysator.liu.se... > Ok thanks for responding. Wouldn't it have been more natural to protect > both the pointer itself and elements pointed to for INTENT(IN) pointers? The intent(in) here refers to the object and to the pointer association status of its pointer component, i.e. it cannot be pointer assigned, or deallocated ("Fortran 95/2003 Explained", Section 5.9). Regards, Mike Metcalf On Apr 27, 2:24 pm, Oskar Enoksson <nob@nowhere.org> wrote: > Ok thanks for responding. Wouldn't it have been more natural to protect > both the pointer itself and elements pointed to for INTENT(IN) pointers? Yes. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare