Home > Archive > Fortran > March 2008 > must presence of optional arguments be verified?
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 |
must presence of optional arguments be verified?
|
|
|
| Hi
Can optional arguments in procedure be forced to be the output
arguments without verifying their presence?
module AAA
contains
subroutine t(b,a)
real, optional, intent(in) :: b
real, optional, intent(out) ::a
! if(present(a))a=11;
a=11;
end subroutine t
end module AAA
program main
use AAA
call t(a=a)
print *,a
end program main
Is "if(present(a))" necessary in the above test program?
Mike
| |
| Richard Maine 2008-03-08, 4:32 am |
| Mike <SulfateIon@gmail.com> wrote:
> Can optional arguments in procedure be forced to be the output
> arguments without verifying their presence?
I can't figure out what that question says, even after looking at the
code. But I can answer the explicit question below about the code.
> module AAA
> contains
> subroutine t(b,a)
> real, optional, intent(in) :: b
> real, optional, intent(out) ::a
> ! if(present(a))a=11;
> a=11;
> end subroutine t
> end module AAA
> program main
> use AAA
> call t(a=a)
> print *,a
> end program main
>
> Is "if(present(a))" necessary in the above test program?
Depends what you mean by "necessary". The above program is standard
conforming, even without the "present" test (unless I overlooked
something). That's because the argument is, in fact, present.
There is nothing "magic" about the present intrinsic. You never "have"
to use it. What you jave to do is avoid referencing or defining dummy
arguments that are not present. The intrinsic provides a handy way to
tell whether an argument is present, but it certainly is not the only
way. In this case, I can tell by looking at the main program that the
argument is present. More realistically, there might be other conditions
that you know to guarantee the presence.
I might say that the above subroutine seems odd in that it has an
argument that has the optional attribute, but it is illegal to call the
subroutine without that argument. That is strange, but allowed. Many
other "strange" things are allowed in the language.
None of this has anything to do with input versus output arguments, and
I still don't understand what the very first sentence above means.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
|
| On Mar 8, 1:27=A0pm, nos...@see.signature (Richard Maine) wrote:
> Mike <Sulfate...@gmail.com> wrote:
>
> I can't figure out what that question says, even after looking at the
> code. But I can answer the explicit question below about the code.
>
>
>
>
>
>
>
> Depends what you mean by "necessary". The above program is standard
> conforming, even without the "present" test (unless I overlooked
> something). That's because the argument is, in fact, present.
>
> There is nothing "magic" about the present intrinsic. You never "have"
> to use it. What you jave to do is avoid referencing or defining dummy
> arguments that are not present. The intrinsic provides a handy way to
> tell whether an argument is present, but it certainly is not the only
> way. In this case, I can tell by looking at the main program that the
> argument is present. More realistically, there might be other conditions
> that you know to guarantee the presence.
If we look at the subroutine only and neglect the caller from main
program, the subroutine doesn't know if 'a' is present, isn't it?
This is what you said above:"avoid referencing or defining dummy
arguments that are not present."
>
> I might say that the above subroutine seems odd in that it has an
> argument that has the optional attribute, but it is illegal to call the
> subroutine without that argument. That is strange, but allowed. Many
> other "strange" things are allowed in the language.
Why do you mean the only one optional argument? Aren't there two
optional arguments: a, b?
It is the output optional argument a that I have a problem.
In fact, I just add the verifying present statement in my working
subroutine (not this simple example), and finally the subroutine works
well now.
Otherwise, the debugger said this optional argument with intent(out)
is undefined pointer/array.
>
> None of this has anything to do with input versus output arguments, and
> I still don't understand what the very first sentence above means.
I am very much appreciated your suggestion.
Mike
| |
| Richard Maine 2008-03-08, 4:32 am |
| Mike <SulfateIon@gmail.com> wrote:
> On Mar 8, 1:27 pm, nos...@see.signature (Richard Maine) wrote:
>
> Why do you mean the only one optional argument?
SInce I didn't say "the only one optional argument", I don't mean
anything by it.
> Aren't there two
> optional arguments: a, b?
Yes, but the other one is completely irrelevant to everything here.
> It is the output optional argument a that I have a problem.
The issue has zero to do with it being an output argument. If you are
looking at anything having to do with being an output argument, then you
are just adding confusion, because that has nothing to do with anything
here. As said before, you cannot reference or define a non-present
dummy.
> In fact, I just add the verifying present statement in my working
> subroutine (not this simple example), and finally the subroutine works
> well now.
Well, if this example doesn't have the problem, then there isn't much
point in showing this example. This example doesn't have any problem at
all as far as I can see (other than looking a bit silly in that it has
an optional argument that may never legally be omitted). If you want
help with a problem, you will have to show the problem, rather than
showing something that doesn't have the problem.
> Otherwise, the debugger said this optional argument with intent(out)
> is undefined pointer/array.
Probably because it isn't present. But then I can't tell as you don't
show the code with the problem.
Again, the "present" intrinsic isn't magic. It does not change anything
about the argument. It just inquires about it. Again (it really is the
whole and entire issue, so it bears repeatng again, and again, and
agfain), it is illegal to reference or define an argument that is not
present. The "present" intrinsic can help you determine when it isn't
present so that you can avoid such illegal references or definitions.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
|
| On 8 mar, 04:43, Mike <Sulfate...@gmail.com> wrote:
> Hi
>
> Can optional arguments in procedure be forced to be the output
> arguments without verifying their presence?
>
> module AAA
> contains
> subroutine t(b,a)
> real, optional, intent(in) :: b
> real, optional, intent(out) ::a
> ! if(present(a))a=11;
> a=11;
> end subroutine t
> end module AAA
> program main
> use AAA
> call t(a=a)
> print *,a
> end program main
>
> Is "if(present(a))" necessary in the above test program?
>
> Mike
As R.Maine explained, considering together the routine definition and
its call statement in the main program you provided, not testing the
presence of the optional argument "a" has no consequence here ...
because the optional argument is really provided by the main program.
Anyway, I highly advise you to test the presence of any optional
argument you want to use in such routine in order to insure that the
routine works correctly for ANY valid call statement.
| |
| Lorenzo `paulatz' Paulatto 2008-03-09, 7:28 pm |
| I feel to add some more practical advice.
Mike ha scritto:
> Is "if(present(a))" necessary in the above test program?
It is not compulsory, but it would be bad practice not putting it. What
will happen if you call the subroutine without the argument "a"? And if
you always put the argument, why have you made it optional?
I could only find one good use for optional variables that do not need a
check for their presence. It uses the fact that presence of an optional
variable is inherited. Read this example:
subroutine first(opt)
integer,optional :: opt
! if(present(opt)) write(*,*) 'opt is present'
call second(opt)
end subroutine first
subroutine second(opt_too)
integer,optional :: opt_too
if(present(opt_too)) &
write(*,*) &
'If and only if the argument is present',//&
'here it was present in first too!'
end subroutine second
LP
--
Lorenzo `paulatz' Paulatto
Trieste
| |
| Richard Maine 2008-03-09, 7:28 pm |
| Lorenzo `paulatz' Paulatto <justforspam@email.it> wrote:
> I could only find one good use for optional variables that do not need a
> check for their presence....
I'd say there were other "obvious" cases where you can deduce the
presence without directly checking for it with the present() intrinsic.
For example, there can be a procedure where there are two optional
arguments, but the procedure is always invoked with either both or
neither of them. In that case, checking one of them can be adequate to
deduce whether the other can also be used.
True, that is not rock solid in that it depends on the assumption that
the procedure is always called "correctly". There could be arguments for
doing the extra verification in some such cases. But it at least isn't
obviously silly or ludicrous to rely on such an assumption, particularly
if the only sensible thing you are going to be able to do on detecting a
violation of the assumption is abort with an error message anyway.
There are other simillar cases where you can deduce the presence based
on other data and requirements, and the use of the present() intrinsic
is no more than a verification that the program has not violated its
conventions.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
|
|
|
|
|