Re: optional routine arguments

On Fri, 8 May 2009, Ian Bush wrote:
On 8 May, 11:45, LC's No-Spam Newsreading account

Compiler is ifort 8.1 (under linux)
Rarely use ifort, but I'm pretty sure that's quite old.

Not intending to upgrade (compiler or OS) until I replace hardware :-)
Hope at the end of the year.

Anyhow that ifort was great for speed and support to f77 legacy code.

[16 lines of my original code snipped]

Firstly I very strongly recommend that the first fancy f95 ( actually
f90 ) feature to use is Implicit None.

implicit none (or some of its variants) did exist as a compiler extension to f77 since at least 16 years. Actually, because of its variants, I always preferred to use an equivalent compiler switch (-u on most Unixes, something else on VMS - yes I'm that old and more :-)) and I regularly do for production programs.

For short test programs I think it's simpler to use the good old I-N rule :-)

In fact for all of the "new" features to do with invoking subprograms that I can think of immediately you need an interface in scope at the calling point. So for your code this becomes

[28 lines of code with explicit interface snipped]

If I run the above I get [what expected]

I confirm my old ifort gets the correct output too !

in reality it is very, very rare that you have to write an interface like the one above. Why ? Because if you use the modern features of contained subprograms or modules

[25 lines of code with module snipped]

and I get the same output as above.

me too

Interfaces are great. Not only do they enable lots of nice new stuff, they also ensure that arguments match - i.e. your program will not even compile if you have an argument mismatch ! How many times has that been a bug in F77 programs ?

Well, I knew of INTENT, INTERFACE and MODULE, and they were in the list among the next cans-of-worms to be opened.

I might appreciate the usage of INTENT to prevent mistakes like passing a constant as an argument which is going to get modified in a subroutine, but I'm not sure I'd like to be "coached" with all match checking (e.g. in the way Java does or beyond). Actually there are cases in which I would not want even type checking (I have for instance a legacy routine which does byteswapping for both a REAL*4 and INTEGER*4, and another lot of telemetry handling routines relying on EQUIVALENCE ....)

I might appreciate the usage of INTERFACE for adding "fancy types" (I was thinking e.g. of one which does error propagation when doing algebra on a quantity +/- error) ... but I think that to be forced to use one in all cases would be an excess of verbosity (compare my 16 lines of code with your 28) ... I feel aestetically uneasy with them (even with all the lot of :: statements).

MODULES was the last can-of-worms I was going to try, mainly because I'm used to things like COMMON blocks, BLOCK DATA, routines rarely in the same source file, and usually in .a or .so libraries, and I'm not sure to understand who manages modules (the compiler or the linker or it depends ?)

So I tried another smaller can-of-worms, i.e. "internal subprograms", which I read about, but could not understand the difference with the good old way to keep a routine in the same source file as the main (I confess I use that very rarely ... if I want to override a library routine with a temporary test variant, or in the same source as a routine, if the second routine is called ONLY and ALWAYS by the first)

Anyhow this 21-line example with no interfaces and no modules, but just a CONTAINS statement, gives the correct output too

Program t
Implicit None
Call sub(1,2)
Call sub(1,2,3)
Contains
Subroutine sub(i,j,k)
Integer, Intent( In ) :: i
Integer, Intent( In ) :: j
Integer, Intent( In ), Optional :: k
Intrinsic present
Write(*,*)' 3 presence flag ',Present(k)
Write(*,*)' 1st arg ',i
Write(*,*)' 2nd arg ',j
If (Present(k)) Then
Write(*,*)' 3rd arg ',k
Else
Write(*,*)' 3rd arg is absent'
Endif
Return
End Subroutine sub End Program t

I could even chop off lines 1,2,7,8 and 10 (and replace the last statement with a plain END) ... and the resulting 16 lines of code (as many as the original ones) do work perfectly.

So it looks like that it is CONTAINS which makes the difference ! At least for ifort. Apparently, as somebody else tested, gfortran is less picky and works with my original (simpler-to-read) code ...

--
----------------------------------------------------------------------
nospam@xxxxxxxxxxxxxx is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
.

Relevant Pages

  • Re: BASIC problem calling LIB$ RTL
    ... The problem was that a routine ... entry point was improperly passed to the LIB$RENAME_FILE RTL. ... This is an arg list, ... So the compiler creates a call block for ...
    (comp.os.vms)
  • Re: Access MDI child properties generically
    ... wouldn't having your child forms implement an Interface ... I have a generic routine to create the TreeView and add it to a form since ... I also would like to add event handlers ...
    (microsoft.public.dotnet.languages.vb)
  • Re: ChannelFactory
    ... das Interface an meine Routine übergeben und er bekommt ein gültiges ... If ServiceInterface.ToString.ToUpper = app.ServiceInterface.ToUpper Then ... End Function ...
    (microsoft.public.de.german.entwickler.dotnet.framework)
  • WCF : ChannelFactory
    ... Interface an meine Routine übergeben und er bekommt ein gültiges Objekt ... Channel erzeugen und mri das "Objekt" zurückgeben. ... End Function ...
    (microsoft.public.de.german.entwickler.dotnet.framework)
  • Re: Java "interface" vs. OO interface
    ... >> interface is implemented near the top of a large hierarchy. ... > different to the rules for routine names? ... Switch statements are kinda bad. ... In that all static entities are "a kinda of" singleton, ...
    (comp.object)
Loading