Home > Archive > Fortran > September 2006 > sequence derived type in common block
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
sequence derived type in common block
|
|
|
| Hi
I encounter the following compiled error:
Error: If a common-block-object is of a derived type, it must be of a
sequence type (R549.f) [S_PAR]
S_PAR in fact is a derived type. I use common block to pass S_PAR
between main & subroutine. Then I get the above error.
What is sequence derived type? I check the help, but I don't
understand.
Thank you for your help.
Mike
| |
| Michael Metcalf 2006-09-26, 8:04 am |
|
"Mike" <acout@yam.com> wrote in message
news:1159276625.497632.78320@i42g2000cwa.googlegroups.com...
> Hi
>
> I encounter the following compiled error:
> Error: If a common-block-object is of a derived type, it must be of a
> sequence type (R549.f) [S_PAR]
>
> S_PAR in fact is a derived type. I use common block to pass S_PAR
> between main & subroutine. Then I get the above error.
>
> What is sequence derived type?
It is a type with the sequence statement added:
type t
sequence
integer :: i
end type t
This allows objects of that type to be storage associated, as you have
observed (see also "Fortran 95/2003 Expained", Section 20.2).
Regards,
Mike Metcalf
| |
| Jan Vorbrüggen 2006-09-26, 8:04 am |
| > What is sequence derived type?
It's a crutch. If you are using derived types at all, at least put its
declaration into a module. And consider replacing COMMON with a MODULE,
also.
But if you can't or won't, place the word SEQUENCE immediately after the
type declaration, and before any members are declared. That will tell the
compiler to consider two declarations of derived type that seem identical
to you to also consider them identical.
Jan
| |
|
|
Jan Vorbr=FCggen wrote:
>
> It's a crutch. If you are using derived types at all, at least put its
> declaration into a module. And consider replacing COMMON with a MODULE,
> also.
I use common block like following:
common /Fun/s, month, iday, s_par
s_par is a derived type. I use this common because I use UVMGS(IMSL
function).
In UVMGS, there required a external FCN which defines minimized
function and is allowed for only one argument. However, my minimized
function is determined by another subroutine containing several
arguments.
How could I replace common with a module (I mean to pass several
arguments to FCN from main program)?=20
Thank you.
Mike
| |
|
|
Mike wrote:
> Jan Vorbr=FCggen wrote:
>
> I use common block like following:
> common /Fun/s, month, iday, s_par
> s_par is a derived type. I use this common because I use UVMGS(IMSL
> function).
> In UVMGS, there required a external FCN which defines minimized
> function and is allowed for only one argument. However, my minimized
> function is determined by another subroutine containing several
> arguments.
> How could I replace common with a module (I mean to pass several
> arguments to FCN from main program)?
..=2E.
Simply declare the variables that are currently in the common in the
module at the module level. This will make them global to all
procedures contained in or that USE the module. In this case, the
external function CONTAINed in a module in which the variables needing
global visibility are defined and then USE that module in the main
program would fairly neatly encapsulate the routine(s) and their
variables. Any which were only needed (if any) for communication
within/between the functions themselves could be made PRIVATE.
Accomplishes the same thing as the COMMON currently does w/ a little
better modularity, so to speak... :)
| |
|
|
dpb wrote:
> Mike wrote:
E,[color=darkred]
> ...
>
> Simply declare the variables that are currently in the common in the
> module at the module level. This will make them global to all
> procedures contained in or that USE the module. In this case, the
> external function CONTAINed in a module in which the variables needing
> global visibility are defined and then USE that module in the main
> program would fairly neatly encapsulate the routine(s) and their
> variables. Any which were only needed (if any) for communication
> within/between the functions themselves could be made PRIVATE.
>
> Accomplishes the same thing as the COMMON currently does w/ a little
> better modularity, so to speak... :)
thank you.
|
|
|
|
|