KlausRamstöck said:
> Consider this situation: a program can run either interactive
>or automatic: In interactive mode, you can fix errors and try again.
>So if something fails, an optional stat argument passes the error
>up the call procedure(s), user gets notified, fights his frustration and
>tries again. In automatic mode, as there is trouble, we print a
>confusing message and quit.
>This codes as:
>
>if(interactive) then
> call do_some_work(stat)
>else
> call do_some_work()
>endif
>
>Not so nice- the same situation occurs in do_some_work and lotsa places.
>
>Now, do_some_work cannot access interactive, as this causes circular
>module dependencies. Besides, i find it quite nice and consistent that
>my routines behave as allocate et al.
I suggest you either:
(1) pass optional arguments consistently, or
One comment: "do_some_work" does not need to access interactive - it
just needs to ask "PRESENT(stat)".
or
(2) use a slightly different mechanism. Various possibilities, like always
passing STAT, with STAT==-1 on input meaning "interactive", or passing
an error control record (derived type), or using alternate returns.
>So I remembered that my NAG f95 seems to pass optional arguments as
>null pointers:
[...]
>and hey! - it worked:
As Richard Maine points out, not with checking enabled:
call tstsub()
Arg present: F
call tstsub(q)
Arg present: T
call tstsub(p)
Reference to POINTER P which is not ASSOCIATED
Program terminated by fatal error
So my advice is not to do it that way.
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|