Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

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

"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

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc