Re: allocatable array *not* equivalent to dynamic allocation?



Lo wrote:

"The Fortran implementation of an allocatable array isn't completely
equivalent to dynamic allocation because it's not possible to use any
element in such a structure until its maximum size has been allocated.
That is, it's not possible to use allocatable arrays to build an
expandable data storage sytructure 'on the fly' ..."

I can't make sense of this. help!


I think most of the people who responded have misinterpreted the passage
you quote and gone off in a tangent direction about reallocation, being
misled by the term "expandable data storage sytructure".

I am fairly sure what the author was really writing about are
structures such as binary trees, linked lists etc, where (usually
fixed size) elements are allocated at run time in response to the data
and algorithms. These allocated data items are *anonymous* (ie
not a named variable) and are referred to by pointers. Such structures
are flexible, and cheaply extensible without requiring any movement of
existing data in memory when inserting a new item. Accessing the
data is done by following a chain of pointers - often using a
recursive routine to traverse the list or tree. Such structures
are the mainstay of many clever computer science techniques.

As such the passage is perfectly correct because Fortran allocatable
arrays are *named* entities and can not point at anything (arrays of
pointers are not allowed). However it is perfectly possible, and
indeed common around these parts to implement such dynamic data
structures using Fortran pointers.

And as a final suggestion to other posters - if you feel the need
for some kind of "realloc" clone this may suggest that your
datastructures are inadequate to the task of dynamically inserting
data and that your program might benefit from linked, dynamic
data structures of exactly this type.

Keith Refson

--
Dr Keith Refson,
Building R3
Rutherford Appleton Laboratory
Chilton
Didcot kr AT
Oxfordshire OX11 0QX isise D@T rl D.T ac D?T uk
.



Relevant Pages

  • Re: INTERFACE problem
    ... I have an integer at Fortran side, pass it by reference to C function, treat here as pointer, allocate memory and this C-pointer at Fortran side now is an integer which has represents address allocated at C side. ... I did something like this many years ago to allow dynamic allocation ... Then it was converted into a subroutine with the arrays and ... it called the sub by way of Pascal with those "pointers". ...
    (comp.lang.fortran)
  • [RFC][PATCH] flexible array implementation v4
    ... I call it a flexible array. ... so never does an order>0 allocation. ... storage for pointers to the second level. ... all locking must be provided by the caller. ...
    (Linux-Kernel)
  • Re: [RFC][PATCH] flexible array implementation v4
    ... I call it a flexible array. ... so never does an order>0 allocation. ... storage for pointers to the second level. ... all locking must be provided by the caller. ...
    (Linux-Kernel)
  • Re: [RFC][PATCH] flexible array implementation
    ... array-like access to such a large structures. ... I call it a flexible array. ... so never does an order>0 allocation. ... storage for pointers to the second level. ...
    (Linux-Kernel)
  • Re: HeapFree() Failure
    ... After all, you are storing pointers to wchar_t, not wchar_t. ... globally defined strings it declares like so: ... Sixteen bytes are successfully allocated to store pointers ... //This memory allocation call will give me sixteen bytes to store four ...
    (microsoft.public.windowsce.embedded)