Re: Automatic (?) array bounds checking

Wow, thanks for the through response!

Yes, subroutines are a lot simpler.

I agree, and the change I proposed would seem to remove any problems.
However, note that if I use a subroutine with

INTEGER, INTENT(OUT) :: v3(SIZE(v1,1)*SIZE(v2,1))

I get the same result as with the function here. Why that is not
detected at runtime is perplexing to me. Maybe I should notify the
gg95 group.

It seems moderately common to find people using functions because they like
the style better, but then having to contort things around the problems
of using functions.

Yes, this function was not originally used in this way; but re-use of
the results became required, and the function is fairly long to call
repeatedly. I just need to go though and replace it (and its cousins)
with subroutines.

My understanding is that in this case, the
function allocates a temporary v3, and then the assignment statement
copies the values (or probably a reference?) to the array c.

From the standard's perspective, it is as you describe first above.

Did you mean that it always copies the values? Or will a reference be
used where practicable?

Keep in mind that a function is
*NOT* necessarily invoked in a simple form like

  variable = function(args)
...

Very true. I could see optimizing these assignments being quite
tricky.

I would say that the main problem here is not the function reference,
but rather the assignment.

That was my thought as well. I just wasn't sure if my understanding
of the process was correct!

Some compilers ought to be able to detect such things as shape mismatch
in an assignment, provided you ask for it. That is, in general a
run-time test and might need a specific switch to turn on.

That's why I gave my option list - maybe someone around here knows if
I'm missing the critical one.

In f2003, one might argue for making variable an allocatable array. In
that case, it will automatically reallocate to the appropriate size when
something is assigned to it.

Ha! That's a good point. In actuality, I was assigning "v3" to an
allocatable array "c"; but I don't think that it was changing size (my
real problem was that I had an input argument "v2" that was too large,
but my "c" was correct for my purposes; and I was surprised when this
wasn't caught at run-time). So I guess if "c" is allocatable, there
just isn't any runtime error to check - perhaps this could be why this
is not a checked for in general.

Thanks again!
.

Relevant Pages

  • Re: destructor advice in F2003
    ... type object that had default initialized components: ... subroutine destroy ... I could make a defined assignment, but I'm really loath to bother with ...
    (comp.lang.fortran)
  • Re: Defined assignment and allocation on assignment
    ... lhs = REPEAT ... END SUBROUTINE assign_udt_to_char ... Defined assignment is really just cute syntax for a CALL statement. ... Then you will get allocation on assignment from the ...
    (comp.lang.fortran)
  • Re: CALL statement in FORALL block
    ... You can't have a CALL statement in a FORALL block. ... an assignment statement can be shorthand for a CALL statement. ... Since it's going to be invoked in a FORALL block, the subroutine ... The most convenient way to make the interface ...
    (comp.lang.fortran)
  • destructor advice in F2003
    ... type object that had default initialized components: ... subroutine destroy ... In F2003 I'd like to make the destroy subroutine a TBP, ... I could make a defined assignment, but I'm really loath to bother with ...
    (comp.lang.fortran)
  • Re: Suppressing intrinsic assignment of derived type
    ... so that an attempt to use intrinsic assignment (versus defined ... SUBROUTINE assign_mytype ... One way of ensuring that the right assignment procedure gets called appears (when supported by enough compilers) to be to make it a type bound procedure. ...
    (comp.lang.fortran)