Re: interface blocks

>> I have about 3500 subroutines with 400,000 lines of f66/f77 that I am
>> porting to use IVF 9.0. I am considering building a generic interface
>> block with all 3500 subroutines in order to ensure that we are not
>> having argument problems (number of and/or data type). I have been
>> told that this might be a bad idea. Why ?
>
> Um. I think you are confusing some terminology.. because that doesn't
> even make sense.... at least not with the word "generic" in there. You
> just mean an interface block rather than a generic one, right? An
> interface block at least makes sense, but a generic one doesn't.

I get terminology confused every day. I meant an interface block for
every subroutine that we have to include. The interface block would
hold the prototype for all subroutines.

> I'd say not so much that doing interface bodies is a bad idea as that
> doing other things (module procedures) is better. Interface bodies can
> give you a false sense of security. To me, one of the big problems with
> interface bodies is that they are usually *NOT* checked against the
> actual procedure. You get checking that the call is compatible with the
> interface body, but what you really wanted was checking that the call is
> compatible with the procedure. Where before, you had only 2 places that
> needed to be compatible (the call and the procedure), you now have 3
> (the call, the procedure, and the interface body). In some ways, this
> overstates the problem, because you only have one interface body per
> procedure, while you presumably have multiple calls. Still, that's the
> crux of the issue.

Well, that is no good. If the prototype is not checked against the actual
subroutine then all is out the door.

> Oh, and there are various annoyances in terms of writing the interface
> bodies correctly, but those are more annoyances than real reasons not to
> do it. Most notable is the mess with interface bodies not getting host
> association. In 99+% of the cases, that just means you have to remember
> the extra trick. In a few special cases, it turns out to be quite hard
> to do at all without a hack introduced in f2003. One is likely to just
> give up on those instead.

So an interface block is not the same thing as an function prototype
in C/C++ ? If so, bummer.

Thanks,
Lynn


.

Relevant Pages

  • Re: Scope of implicit none
    ... That seems to indicate that the IMPLICIT NONE statement is ... statement make itself felt inside an interface block. ... that maybe the f90 interp wasn't such a good idea ...
    (comp.lang.fortran)
  • Re: Fortran 2003: abstract interfaces
    ... I'm suspicious that you are confusing an interface and an interface ... particular procedure has a particular abstract interface, ... An interface block can define one or more interfaces. ... interface body specifies what specifics are included in the generic. ...
    (comp.lang.fortran)
  • Re: Pointers to procedures in Intel Fortran
    ... Intel Fortran supports using integer pointers where the pointee is named in a ... specific interface block, but NOT if it's a generic interface name. ... support pointee generics either. ...
    (comp.lang.fortran)
  • Re: Interface declarations
    ... function, it must also have an interface block for f_dummy2, right? ... have an interface block for their f_dummy*() dummy argument. ... Scope doesn't work that way. ...
    (comp.lang.fortran)
  • Re: explicit interface of a module function
    ... Forget the interface bodies for a while longer then. ... For that you need an interface block, but not an interface body. ...
    (comp.lang.fortran)