Re: Arrays of zero length



In article <dhm6df$3hg$1@xxxxxxxxxxxxxxxxxx>,
"gh14tq5@xxxxxxxxx" <gh14tq5@xxxxxxxxx> wrote:

> What are the ramifications of allocating vectors (arrays) of zero
> length, e.g.,

Works fine. Most things should be fairly "obvious" (for some definition
of the term). There is only one things that I find majorly "strange",
and one thing that I sometimes find minorly so.

The major strangeness has to do with association. It is too ugly to go
into in detail here. I never did like the special rule for association
of zero-sized objects and I still think it is broken, although I've
heard the (rather extended) debates on it. Basically, all zero-sized
arrays are associated with each other (provided they have the same type,
kind, and rank). I find that just unbelievably strange. For example, it
is so even if they are in different common blocks. So don't count on the
associated intrinsic telling you useful things with zero-sized arrays.
But I'm betting you aren't doing anything related to that.

The minor strangeness is that when you allocate an array to zero size,
the array is defined (n the sense of having a value). For any other
size, the array is undefined right after allocation. This does make
sense to me when I think about it because to define an array, you define
all its elements; that's already done for all zero of the elements when
you allocate a zero-sized array. I suppose the biggest reason I notice
this as an oddity is that the standard special-cases the description of
this, saying something like that allocating an array makes it undefined
unless it is of zero size (that's not an exact quote).

Your example is slightly related to this one, depending on the point of
view. Since vec is defined after allocating it to zero size, it is ok to
reference it. Now vec(1) isn't defined (and worse - isn't a valid
variable at all because of the subscript error), but vec is ok.

> If I try to access the array explicitly
>
> vec(1) = 1
>
> then of course I get a memory error,

As you say, of course.

> but if I do something like
>
> vec = vec + 10
>
> everything is fine (Intel Fortran compiler).

Yes. This operation was done to all the elements - all zero of them.
Think of this as being somewhat like (there are differences in other
aspects, but none of them affect this simple case)

do i = 1 , size(vec)
vec(i) = vec(i) + 10
end do

If the size is zero, the body of the DO loop is executed all zero times.
None of the (zero) times that it executes is there a problem.


> In these cases, I can either check
> the length of the vectors in every place in my code that those vectors
> occur and skip the instructions if the length is zero. Or, if it's
> permissible to have zero length vectors, I only have to check for the
> vector length at those spots where a vector location is explicitly
> accessed, e.g. vec(1). Are zero length alloctable vectors (or
> non-alloctable) allowed by the Fortran standard?

Yes, they are fine as of f90 - even the non-allocatable ones. And yes,
to other readers, there are multiple situations where zero-sized
non-allocatable vectors are useful. In f77, zero-size was disallowed,
but that restriction was lifted as of f90.

I consider this *VERY* much like the lifting of the restriction against
zero-trip DO loops in f77. There are cases where it makes perfect sense.
In f66, one often had to specially test for that case and branch around
the DO loop, while in f77 it just works. Likewise, in f90, the zero-size
cases just work as long as you have written the code in ways that
logically extrapolate to the zero-size case, as your example (and most
of them) DO.

P.S. Since I mentioned zero-trip DO loops, I'll forestall having to
correct someone posting the widespread myth that f66 did one trip in
those cases. Instead I'll post my correction before the fact, probably
creating a space-time loop by causing the future post that I'm referring
to to not appear. The f66 standard just said that code with such loops
was illegal, just like the f77 standard says that code with zero-sized
arrays or zero-length strings is illegal. Actual f66 compilers varied in
how they handled the nonstandard case, but ignorance of the standard
lead a lot of people to assume that the behavior of some particular
compilers was specified in the f66 standard; it wasn't, and other f66
compilers had different behaviors.
.



Relevant Pages

  • Re: should every thing be zero indexed?
    ... Other families of languages count from 1. ... its number is zero: I always start counting at zero". ... > as a fundamental concept in both the definition of array indices and ... > for I in foo'range loop ...
    (comp.programming)
  • Re: Subset Sum problem (w/ limited scope)
    ... The "Subset Sum" problem (stated various ways depending on what you ... a subset of those integers that sums up to zero. ... Are there going to be duplicate values in your original array? ...
    (comp.lang.fortran)
  • Re: addEvent - The late entry :)
    ... take any number of arguments and append them to an array. ... argument, which is fine on everything but Firefox, where it makes the ... 20 arguments Windows Safari 3 executes that expression in 48% of the ... and at zero arguments 47%. ...
    (comp.lang.javascript)
  • Re: Subset Sum problem (w/ limited scope)
    ... The "Subset Sum" problem (stated various ways depending on what you ... a subset of those integers that sums up to zero. ... Are there going to be duplicate values in your original array? ...
    (comp.lang.fortran)
  • Re: initializing an array of user-defined data types
    ... After allocating it, I want to initialize it so that after ... because your array is allocatable. ... You could even use NULLby having a component of piece be a pointer, ...
    (comp.lang.fortran)