Home > Archive > Fortran > November 2005 > Re: the problem of declaring a function in the interface
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 |
Re: the problem of declaring a function in the interface
|
|
| Jurang 2005-11-18, 7:01 pm |
| right this is xlf. Thank you, Dan
But the funny thing is that in the function precedure below, there is
no error.
then that looks like it supports the allocatable function procedure.
When I take "allocatable" out in the interface block and the function
procedure, still I have the same error.
This time the errors point to the both.
I just need a function result array.
Is there any way I can code a function with a result array in an
interface and a procedure?
thank you.
| |
| Dan Nagle 2005-11-18, 7:01 pm |
| Hello,
Work-around number one is, if allocatable can't be used
for whatever reason, try using pointers instead. You
lose some safety and efficiency, but you just have
to be careful and muddle through until your compiler
supports allocatable function results.
Second choice might be to rewrite as a subroutine.
Jurang wrote:
> right this is xlf. Thank you, Dan
>
> But the funny thing is that in the function precedure below, there is
> no error.
> then that looks like it supports the allocatable function procedure.
>
> When I take "allocatable" out in the interface block and the function
> procedure, still I have the same error.
> This time the errors point to the both.
>
> I just need a function result array.
> Is there any way I can code a function with a result array in an
> interface and a procedure?
>
> thank you.
Your welcome.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard E Maine 2005-11-18, 7:01 pm |
| Jurang <yegakjh@gmail.com> wrote:
> When I take "allocatable" out in the interface block and the function
> procedure, still I have the same error.
> This time the errors point to the both.
Yes. I was wondering about that diagnosis. Although this is an f2003 (or
f95+TR) feature, the error message didn't sound like it was griping
about that.
Off-hand the code looks ok to me, and NAG accepts it happily (other than
griping about allocatable functions being an extension and about unused
dummy args) once I replace the USE const with a definition of dp and
comment out the other USE.
Although I don't see anything obviously wrong, two points make me
slightly wonder about other issues.
1. In what context do you ever make use of the def_fncs module? In
particular, it has an interface body for up_mv_mul, which is the name a
module procedure in the other module. You do no need and cannot have an
interface body for a module procedure. Since these are in different
modules, they don't necessarily clash, so it isn't technically wrong....
yet. But it is sure confusing, and as soon as you try to use both
modules at the same time, there will be a clash.
2. I assume that "use const" is to get the dp parameter, but what is the
"USE cheb_grid"? I don't see what is in it, raising the possibility of
clashes. Since it doesn't appear to be needed in the code swhown, that
also raises the question of whether you exerpted this from a larger
module, which might have had other things contributing to the problem.
I guess my question boils down to wondering whether this is a complete
sample illustrating the problem? Since the problem is in compilation
instead of in execution, we don't need a runnable sample, but I'd like
to verify with a compilable one. This looks *AWFULLY* close. Get rid of
the "USE cheb_grid", either provide a trivial const module defining DP
or just hack in a replacement definition for it for illustrative
purposes. Make sure you really have nothing else in teh file. Then see
if you get the same error. Oh, and since the 2 modules are independent
and can't even be used together, I'd also be tempted to put them in
separate files; shouldn't matter, but there is always a possibility that
something is getting  in the compiler by having them together
(if information from the first module isn't completely cleared out
before processingthe second).
--
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
| |
| Richard E Maine 2005-11-21, 7:01 pm |
| Jurang <yegakjh@gmail.com> wrote:
> As Richard suggested, I separated two modules in different files and
> try not to use "use" and took out unnessary part now.
[elided]
Well, that does make it pretty clear now. Nice, completely
self-contained check case with perfectly fine code. If the compiler
claims to support the allocatable TR, then this would be a compiler bug
(and it is the kind of bug report that compiler-writers love, being
small and self-contained).
The only remaining question would be whether the version of the
copmpiler that you have claims to support the TR. Well, not quite the
only question, as even if the compiler didn't support the TR, I'd say
that the error message was misleading enough to merit a bug report.
If your version of xlf is current, I'd suggest submitting this as a bug
report.
--
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
|
|
|
|
|