allocatable vs non-allocatable arrays 
Author Message
 allocatable vs non-allocatable arrays

Hi,

I'd like to ask your opinion on whether or not arrays should always be
allocatable or not. Consider the the example program below. I have two
versions of essentially the same routine. Once the dummy array argument
is allocatable, once it's not.

If I use the first version ("test"), I can compile and run it both with
an allocatable (b) and a non-allocatable (a) actual argument. calling
test(b) causes a segfault. Of course, had I allocated b before calling
test(b), it would work.

If I'm looking for robustness (imagine the test routine being in a
library that I'm writing, where I have no control over how someone
might call it) this possibility of a segfault is pretty bad. There is
no way for me to check inside the test routine whether or not the dummy
argument is allocated.

The alternative is using the test2 routine. This case seems very robust
to me. If it compiles, I can make sure it works correctly by checking
the allocation status of the array. There's no possibility of an
unexpected error. The price is that it will only compile if the actual
argument is declared as allocatable. Hence the test2(a) call doesn't
work.

If I decided to make all arrays allocatable inside my library, I would
reach maximum robustness, but I'd impose on the person using the
library that she'd have to make all her arrays allocatable as well.
Still this seems like that best option. What do you think? Are there
any consideration I have neglected?

This is specifically for fortran 90, of course.

Thanks,
Michael

---------- %< ----------------
program aatest
  real :: a(5)
  real, allocatable :: b(:)

  call test(a)
  !call test(b)  ! segfault
  !call test2(a) ! doesn't compile
  call test2(b)

contains

    subroutine test(a)
      real :: a(:)
      write (*,*) size(a)
      write (*,*) a(1)
    end subroutine test

    subroutine test2(a)
      real, allocatable :: a(:)
      if (allocated(a)) then
        write (*,*) size(a)
        write (*,*) a(1)
      else
        write (*,*) "not allocated"
      end if
    end subroutine test2

end program aatest
---------- %< ----------------



Sun, 24 Jul 2011 02:28:00 GMT  
 allocatable vs non-allocatable arrays

Quote:
> I'd like to ask your opinion on whether or not arrays should always be
> allocatable or not. Consider the the example program below. I have two
> versions of essentially the same routine. Once the dummy array argument
> is allocatable, once it's not.

As far as I know, allocatable dummy arguments should be used
only when the called routine has to change the size, including
allocating it the first time.

Quote:
> If I use the first version ("test"), I can compile and run it both with
> an allocatable (b) and a non-allocatable (a) actual argument. calling
> test(b) causes a segfault. Of course, had I allocated b before calling
> test(b), it would work.

Yes, but there is no reason to do that.  There is no useful
thing a called routine can do with a non-allocated array passed
to a non-allocatable dummy.  (I believe just calling it is
non-standard, but definitely referencing it is wrong.)

Put if(allocated(b)) on the call statement.

Quote:
> If I'm looking for robustness (imagine the test routine being in a
> library that I'm writing, where I have no control over how someone
> might call it) this possibility of a segfault is pretty bad. There is
> no way for me to check inside the test routine whether or not the dummy
> argument is allocated.

Doing just about anything with a non-allocated array except
allocating it or passing it to an allocatable dummy is likely
to get you a segfault.  Don't do it.

Quote:
> The alternative is using the test2 routine. This case seems very robust
> to me. If it compiles, I can make sure it works correctly by checking
> the allocation status of the array. There's no possibility of an
> unexpected error. The price is that it will only compile if the actual
> argument is declared as allocatable. Hence the test2(a) call doesn't
> work.

It seems less robust to me, it fails if you try to pass a
non-allocatable array.  (I don't know that the standard
requires that to be noted at compile time, though in your
example it is diagnosed.

Quote:
> If I decided to make all arrays allocatable inside my library, I would
> reach maximum robustness, but I'd impose on the person using the
> library that she'd have to make all her arrays allocatable as well.
> Still this seems like that best option. What do you think? Are there
> any consideration I have neglected?

(snip)

-- glen



Sun, 24 Jul 2011 02:45:32 GMT  
 allocatable vs non-allocatable arrays

Quote:

> > If I use the first version ("test"), I can compile and run it both with
> > an allocatable (b) and a non-allocatable (a) actual argument. calling
> > test(b) causes a segfault. Of course, had I allocated b before calling
> > test(b), it would work.

> Yes, but there is no reason to do that. ?There is no useful
> thing a called routine can do with a non-allocated array passed
> to a non-allocatable dummy. ?(I believe just calling it is
> non-standard, but definitely referencing it is wrong.)

Yup, non-standard. Take a look at

http://preview.tinyurl.com/ctlnql

( goes to an earlier clf thread )

And I've definitely encountered seg-faults because of this,

Ian



Sun, 24 Jul 2011 16:25:49 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Allocatable array of allocatable defined types?

2. Pointers vs. allocatable arrays in derrived types

3. pointers vs allocatable arrays

4. ALLOCATABLE arrays vs POINTERs

5. Efficiency of pointer vs. allocatable arrays in F90

6. Allocatable derived type with allocatable components in fortran 90

7. allocatable non-dummy local variables and pointers to them

8. Possible to return an allocatable array?

9. Allocatable Arrays in Fortran 90

10. appending elements to an ALLOCATABLE array

11. help reg ALLOCATABLE arrays with INTENT statement

12. ALLOCATABLE arrays

 

 
Powered by phpBB® Forum Software