On Sep 22, 2004, at 8:36 AM, Aleksandar Donev wrote:
> The question was whether this is a runtime-only (as you claim) or a
> compile time checkable (given the whole program and a super-smart
> compiler) constraint.
Well, part of the answer is trivial. The standard is pretty explicit
about
constraints. They all start with "Constraint:" in f95, or with A C
number
in f2003. This isn't one.
But I suspect you are using the term "constraint" differently than
the standard does. In the standard, "constraint" is not a
synonym for "compile-time checkable". All constraints are designed
to be compile-time checkable, but there are certainly things that are
not constraints that are also compile-time checkable, at least in
special cases and sometimes even in general.
Anyway, to answer the question instead of snip at terminology, I
see no possible way that all cases of this can be checked at
compile time. Certainly some trivial cases could be, but just as
certainly, some other cases cannot possibly be. Trivial example
with details omitted and pseudo-code instead of real syntax
read in logical L
if (L) then
P => something valid to deallocate
else
P=> something not valid to deallocate
endif
read in another logical M
if (M) deallocate(P)
Silly, I agree, but I wanted just enough to prove the point in
principle, without bothering to think up something useful.
I have to disagree with Dan in that I find the question nontrivial.
I'm not even 100% sure I know the answer, and I'm afraid I
don't have time to research it now. My off-the-top of-my-head-
and-very-possibly-wrong answer is that Q(i:j) is never something
that can be deallocated, regardless of the values of i and j.
I think that Q(i:j) is fundamentally a slice. It may happen to
be a slice that has all of the elements, but it is still a slice. Slices
aren't deallocatable.
If you look at the definition of a pointer assignment statement,
you'll see that you are off in different parts of the definition with
the 2 forms(P and Q both pointers)
P => Q
P => Q(i:j)
The first form is the case where the RHS is a pointer. The second form
is the case where the RHS is a target. I think the difference matters.
Much like X(:) is not allocatable even if X is; this distinction
matters in
things like the f2003 extensions to assignment.
So I think the code shown is invalid, regardless of the values read in,
although compilers are not obligated to catch the error.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|