Re: Allocatables in derived types and functions
- From: nospam@xxxxxxxxxxxxx (Richard E Maine)
- Date: Wed, 11 Oct 2006 09:18:05 -0700
Arno <arnoinperu@xxxxxxxxxxx> wrote:
[has a function get_i, which returns an allocatable result]
Now I was wondering if I am allowed to use this function as an argument
in a function call?
Yes, (all assuming that the compiler supports the allocatable TR in
order to have allocatable components and allocatable function results at
all), however...
For example:
call write_i(get_i(object))
That is *NOT* an example of using the function as an argument in a
function call. If you had
call write_i(get_i)
then that would be using the function as an argument in a function call.
Both forms are allowed (with appropriate changes in write_i), but they
mean completely different things.
What you have is an example of using the function *RESULT* as an
argument. The difference is quite important. That does also happen to be
allowed.
subroutine write_i(i)
integer,dimension(:),intent(in) :: i
Here, I think, is your problem. It actually has nothing to do with your
function get_i at all.
Your subroutine write_i has an assumed-shape dummy argument. Tis means
that write_i requires an explicit interface. Since you didn't mention
this or showanything that obviously provides one, I'm betting that you
don't have one and that this is your problem.
Pretty much all of the features that are new to f90 or later and have
anything to do with procedure arguments require an explicit interface.
This is one of them. Functions with allocatable results are another. I
recommend routine providing an explicit interface for all procedures,
whether they require it or not. This keeps you from having to memorize
the list of conditions and remembering to think about it all the time -
particularly if you change a procedure in a way that adds the
requirement.
If you are using the kinds of things shown in your example, you are
likely to run into explicit interface requirements a lot.
The simplest way to provide an explicit interface is to put all the
procedures in modules; that makes the explicit interfaces automatic.
If your procedures are already all in modules, then perhaps it is
something else. But you didn't explicitly mention that, and it is a
*CRITICAL* point. This makes me think that you are not aware of the
issue, or perhaps forgot about it when posting this query. (Lots of
people aren't aware of the issue; variants of it are high on the
frequently asked questions list here).
It is also true that, even with the required explicit interfaces, your
example is a reasonable "stress test" for implementation of the
allocatable TR. (And actually passing the function would be another good
test). But I think we need to make sure that the code is actually
correct before going there.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.
- Follow-Ups:
- References:
- Allocatables in derived types and functions
- From: Arno
- Allocatables in derived types and functions
- Prev by Date: Re: fortran dll and VB callback
- Next by Date: Re: Logical expressions with integer operands
- Previous by thread: Re: Allocatables in derived types and functions
- Next by thread: Re: Allocatables in derived types and functions
- Index(es):
Relevant Pages
|
