Alvaro Fernandez writes:
> Can an automatic array have the optional attribute?
No, but that's because you have the wrong terminology.
An automatic array is never a dummy argument - that's part of the
definition of "automatic". What you mean is an adjustable array.
Yes, an adjustable array may have the automatic attribute.
> If so, does that mean it
> is only allocated inside an IF(PRESENT()) block?
This question doesn't make sense because
1. "Allocated" has a specific technical meaning and applies only to
allocatable arrays....that is ones with the allocatable attribute,
which you don't have here.
So the concept of "allocated" just doesn't apply. Do you mean
something esoteric (if so, I can't figure out what) or are you
just asking about whether you can reference the array?
2. There is no such thing as an "if(present())" block.
PRESENT is an intrinsic function. That is *ALL*. It has
nothing to do with any kind of block structure.
So lets go back to what I'm guessing you really want to know.
The limitations on optional arguments don't have anything to do with
whether or not the argument is an adjustable array or not. There is
a list of things that you can't do with an optional argument that
is not present (basically, you can't do much). It is the same list
independent of whether or not the argument is an adjustable array.
I hope that answers part of the question.
For what I think is the other part of the question, the conditions on
what you can do with an optional argument depend on whether or not the
argument is present. The PRESENT() intrinsic can be used to determine
whether or not the argument is present, but the conditions do *NOT*
depend on you actually useing the PRESENT() intrinsic. It is often
convenient to do so, but you don't have to. Even if you use the
intrinsic, it does not have to be used in a block structure. If the
argument is present, then it is present regardless of whether you use
the present intrinsic or not.
It is quite possible for you to deduce the presence from data other
than the present intrinsic. You could, for example, take a
nonoptional argument and just add the optional attribute to it,
knowing that it is always actually present. You then wouldn't need to
use the present() intrinsic at all - you'd just know that it was
alwats present because you know that's the way you wrote the code.
I don't recommend this as a good coding style; I'm just using it as
an extreme case to point out that it is legal.
Now there is one interaction between adjustable arrays and
optionality, but it is a different case than the one you are asking
about. There is nothing special about the array being optional,
but there is something special about the array bound being an optional
dummy. For example, the following is illegal
subroutine sub(n,c)
integer, optional :: n
real :: c(n)
The bound expressions for c have to be specification expressions,
and specification expressions can't use optional dummies. That's
basically because specification expressions need to be evaluatable
on entry to the subroutine and optional dummies aren't evaluatable
when they aren't present. (The standard doesn't use the word
"evaluatable", and I wouldn't count on it being a word at all, but
I thought it the best way to informally express the idea).
So the problem here is with n being optional; c being optional
would raise no special issues.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|