|
|
 Up |
|
|
  |
Author: rudrarudra Date: Aug 4, 2008 12:40
hello friends,
in Chapman's book, the "Good programming practice" advices to prefer
module over interface to make explicit interface of a subroutine/
function. where i have many subroutine contained in a module, it is
understood that i can use onle the subroutine which is needed instead
of make interface for each subroutine.
but if i have only one subroutine(say), is there any advantage of
using module over interface?
or in general,is there any advantage of using module over interface
except decreasing typo labour?
|
| |
|
| | 14 Comments |
|
|
Author: Steve LionelSteve Lionel Date: Aug 4, 2008 12:58
On Mon, 4 Aug 2008 12:40:10 -0700 (PDT), rudra gmail.com> wrote:
>but if i have only one subroutine(say), is there any advantage of
>using module over interface?
>or in general,is there any advantage of using module over interface
>except decreasing typo labour?
If you have only one subroutine, then perhaps you just want to make it a
CONTAINed procedure of the main program. This gives you the same advantages
as a module regarding an explicit interface.
I am of the opinion that INTERFACE blocks (other than for defining generics)
should be reserved for non-Fortran code or for integrating "legacy" code into
your application.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
|
| Show full article (1.00Kb) |
|
| | no comments |
|
|
Author: Craig PowersCraig Powers Date: Aug 4, 2008 13:11
rudra wrote:
> hello friends,
> in Chapman's book, the "Good programming practice" advices to prefer
> module over interface to make explicit interface of a subroutine/
> function. where i have many subroutine contained in a module, it is
> understood that i can use onle the subroutine which is needed instead
> of make interface for each subroutine.
> but if i have only one subroutine(say), is there any advantage of
> using module over interface?
> or in general,is there any advantage of using module over interface
> except decreasing typo labour?
Typo labour = greater opportunity to make mistakes which results in bugs
in your program.
In other words, that alone is reason enough to prefer a module.
|
| |
| no comments |
|
|
Author: James GilesJames Giles Date: Aug 4, 2008 13:23
Steve Lionel wrote:
> On Mon, 4 Aug 2008 12:40:10 -0700 (PDT), rudra gmail.com>
> wrote:
>>> but if i have only one subroutine(say), is there any advantage of
>> using module over interface?
>> or in general,is there any advantage of using module over interface
>> except decreasing typo labour?
>
> If you have only one subroutine, then perhaps you just want to make
> it a CONTAINed procedure of the main program. This gives you the
> same advantages as a module regarding an explicit interface.
But it also has the disadvantage that *all* the local variables
of the host program unit are visible to the CONTAINed procedure,
no matter how important it is that such an internal procedure
*NOT* have such access. Like the iteration variables for your
loops, or some temporary index you're saving, etc.
Stick to USEing modules. Internal procedures are for the kinds
of things statement functions used to do.
|
| Show full article (1.26Kb) |
| no comments |
|
|
Author: James GilesJames Giles Date: Aug 4, 2008 13:31
Craig Powers wrote:
> rudra wrote:
>> hello friends,
>> in Chapman's book, the "Good programming practice" advices to prefer
>> module over interface to make explicit interface of a subroutine/
>> function. where i have many subroutine contained in a module, it is
>> understood that i can use onle the subroutine which is needed instead
>> of make interface for each subroutine.
>> but if i have only one subroutine(say), is there any advantage of
>> using module over interface?
>> or in general,is there any advantage of using module over interface
>> except decreasing typo labour?
>
> Typo labour = greater opportunity to make mistakes which results in
> bugs in your program.
|
| Show full article (1.62Kb) |
| no comments |
|
|
Author: Craig PowersCraig Powers Date: Aug 4, 2008 14:43
James Giles wrote:
> Craig Powers wrote:
>> rudra wrote:
>>> hello friends,
>>> in Chapman's book, the "Good programming practice" advices to prefer
>>> module over interface to make explicit interface of a subroutine/
>>> function. where i have many subroutine contained in a module, it is
>>> understood that i can use onle the subroutine which is needed instead
>>> of make interface for each subroutine.
>>> but if i have only one subroutine(say), is there any advantage of
>>> using module over interface?
>>> or in general,is there any advantage of using module over interface
>>> except decreasing typo labour?
>> Typo labour = greater opportunity to make mistakes which results in
>> bugs in your program.
>
> Well, that's a result of a bad language design issue though. The
> standard should have required implementations to be able to
> detect and report mismatches between an interface and the
> corresponding procedure. ...
|
| Show full article (1.09Kb) |
| no comments |
|
|
Author: James GilesJames Giles Date: Aug 4, 2008 15:07
Craig Powers wrote:
> James Giles wrote:
>> Craig Powers wrote:
...
>>> Typo labour = greater opportunity to make mistakes which results in
>>> bugs in your program.
>>
>> Well, that's a result of a bad language design issue though. The
>> standard should have required implementations to be able to
>> detect and report mismatches between an interface and the
>> corresponding procedure.
>
> I can't say I'd be wild about the two feasible approaches to this
> that I can see: automatic interface generation as done by ifort or
> C++-style name mangling.
Most implementations these days come with a loader (some
call it a linker). Why not a load-time interface checker packaged
with the loader? Or, some separate load-time tool that runs
with, or prior to, the loader?
|
| Show full article (1.11Kb) |
| no comments |
|
|
Author: Craig PowersCraig Powers Date: Aug 5, 2008 10:25
James Giles wrote:
> Craig Powers wrote:
>> James Giles wrote:
>>> Craig Powers wrote:
> ...
>>>> Typo labour = greater opportunity to make mistakes which results in
>>>> bugs in your program.
>>> Well, that's a result of a bad language design issue though. The
>>> standard should have required implementations to be able to
>>> detect and report mismatches between an interface and the
>>> corresponding procedure.
>> I can't say I'd be wild about the two feasible approaches to this
>> that I can see: automatic interface generation as done by ifort or
>> C++-style name mangling.
>
> Most implementations these days come with a loader (some
> call it a linker). Why not a load-time interface checker packaged
> with the loader? Or, some separate load-time tool that runs
> with, or prior to, the...
|
| Show full article (1.13Kb) |
| no comments |
|
|
Author: James GilesJames Giles Date: Aug 5, 2008 10:58
Craig Powers wrote:
> James Giles wrote:
....
>> Most implementations these days come with a loader (some
>> call it a linker). Why not a load-time interface checker packaged
>> with the loader? Or, some separate load-time tool that runs
>> with, or prior to, the loader?
>
> Most implementations these days piggy-back on some sort of "system"
> linker (Microsoft's link.exe or the system ld, AFAIK). In the case of
> link-time optimization, I guess it would be feasible to hoist
> interface checking into that tool, but otherwise, I think you're back
> to something like ifort's interface generation.
I have never used ifort's interface generation. It sounds like
a backwards thing. The idea is to check their validity, not
generate them. Most editors with drag-and-drop capability
make the job of generating them pretty simple as-is.
|
| Show full article (2.22Kb) |
| no comments |
|
|
|
|
|
Author: Craig PowersCraig Powers Date: Aug 5, 2008 11:14
James Giles wrote:
> Craig Powers wrote:
>> James Giles wrote:
> ....
>>> Most implementations these days come with a loader (some
>>> call it a linker). Why not a load-time interface checker packaged
>>> with the loader? Or, some separate load-time tool that runs
>>> with, or prior to, the loader?
>> Most implementations these days piggy-back on some sort of "system"
>> linker (Microsoft's link.exe or the system ld, AFAIK). In the case of
>> link-time optimization, I guess it would be feasible to hoist
>> interface checking into that tool, but otherwise, I think you're back
>> to something like ifort's interface generation.
>
> I have never used ifort's interface generation. It sounds like
> a backwards thing. The idea is to check their validity, not
> generate them. Most editors with...
|
| Show full article (1.74Kb) |
| no comments |
|
|
|
|
