On Sep 30, 2004, at 9:32 AM, John Vaul wrote:
> The IBM compiler I am using complains when I pass as an argument to a
> subroutine
> an item of a derived type which is itself a derived type. Is it right
> to complain?
Probably... because I bet you are misinterpreting the messages and the
situation. I seriously doubt that it has anything to do with passing a
derived type component (which is what your example is doing. You have a
derived type that has components of other derived types; it doesn't
actually make sense to say that a derived type is itself a derived
type... well, to the extent that it makes sense it is just a
tautology).
In order to be sure, I'd need to see more context of the code, plus the
error message. The excerpt and the fact that the IBM compiler
"complains" isn't enough. So if I'm wrong, you need to provide the
extra information. But I'd place fairly good odds on the problem
being...
Where does the subroutine mysub get its definition of the type freq
from? You don't show. It matters. A lot. If you just have another copy
of the definition of type freq in mysub, then that is your problem.
Unless they are sequence types, two different derived type definitions
define 2 different types. That is true even if the two definitions are
textually 100% identical - or even if they come from an include file
that is included twice. They still count as different, which means that
the types of your actual and dummy arguments don't match.
If you want the types of the actual and dummy arguments to match when
using derived types, you need to either
1. Make them both sequence types,
2. Have the subroutine be an internal procedure, getting the type by
host association.
2. Put the type definition in a module and USE the module.
Option 1 may be the simplest choice for you for now. But eventually, I
recommend option 3. A lot of things in f90 really work much more
cleanly with modules; derived types are just one case. If you don't
choose option 3, I predict you will be back around later to discover
that some of your subroutines need explicit interfaces (which is best
solved by putting them in modules). Option 2 has limited applicability;
I mention it just for completeness.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|