Re: appending elements to an ALLOCATABLE array
From: glen herrmannsfeldt (gah_at_ugcs.caltech.edu)
Date: 02/26/04
- Next message: Gordon Sande: "Re: INCLUDE file"
- Previous message: Richard Maine: "Re: Use of subroutines"
- In reply to: Ed Wells: "Re: appending elements to an ALLOCATABLE array"
- Next in thread: Richard Maine: "Re: appending elements to an ALLOCATABLE array"
- Reply: Richard Maine: "Re: appending elements to an ALLOCATABLE array"
- Reply: James Van Buskirk: "Re: appending elements to an ALLOCATABLE array"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 26 Feb 2004 17:42:28 GMT
Ed Wells wrote:
> Richard Maine <nospam@see.signature> wrote in message news:<m11xokf5wc.fsf@macfortran.local>...
>>glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>Maybe I am completely missing the point, but I don't think so.
>>>C has realloc() to reallocate a region of malloc()'ed memory
>>If you are getting the point, then I'm missing it. Look at
>>the originally posted code. Now perhaps that would be a different
>>way of achieving the ends, but that doesn't look at all like the
>>means that he asked for. It had examples like (not rechecking
>>exact names)
>>
>> p => (/ a, b /)
>>
>>where a and b had previously been allocated quite independently.
>>That's not a realloc.
The beginning of this thread, where the subject does not have an Re:
pure subroutine append_vec(ii,ivec)
! append ii(:) to ivec(:)
integer, intent(in) :: ii(:)
integer, intent(in out), allocatable :: ivec(:)
integer, allocatable :: jvec(:)
integer :: ni,nv,n
ni = size(ii)
if (allocated(ivec)) then
nv = size(ivec)
allocate (jvec(nv))
jvec = ivec
deallocate (ivec)
n = ni + nv
allocate (ivec(n))
ivec(:nv) = jvec
ivec(nv+1:) = ii
else
allocate (ivec(ni))
ivec = ii
end if
end subroutine append_vec
Then James Giles post included the line:
> ivec = [ivec(:), ii(:)] ! instead of CALL APPEND_VEC(ivec, ii)
and Ed Wells posted
> ! An to increase our allocated memory, wouldn't it be nice to do this:
> a => (/ a, b /) ! Now a points to memory held by a and b.
> Yes, I wished to know the feasability (i.e., why don't we already have
> this) of addressing more than one pre-allocated memory locations using
> a pointer. In essence, this feature would allow you to expand memory
> addressed by a pointer by pointing to more memory. In practice, this
> may not be possible.
>>Now I agree that perhaps the OP would have been better served
>>(and I should have thought of suggesting) that he look at the
>>problem to be solved instead of at the proposed solution.
> My original post (not the OP, as that was someone else, and I hijacked
> the thread), was a little mirky on what problem I proposed. I gave a
> syntax that I hoped showed the nature of the problem, though it was
> insufficient. I hope my subsequent post clarified that.
>>As a proposed solution, I don't think what he asked for works.
>>But if the problem is the realloc problem, then there are
>>other approaches (though I think you are dreaming if you
>>think that most realloc's can be done in place with no copies).
As I said somewhere else, the way I usually use realloc() in C
it usually can be, but that is a small set of the possible
uses for it. Also, even if it can be done in place, one still
wants to avoid it to some extent by increasing the size in
large enough amounts.
>>>Lacking that feature,
>>>he at least wanted one that only required one copy.
>>For pointer allocation, you only need one copy today.
>>For allocatables, you need 2 today; the move-alloc procedure
>>of f2003 is intended to address that.
> Actually, expanding a bit, the problem is how to address
> non-contiguous sections of preallocated non-contiguous memory in an
> efficient and convenient matter. It is not a problem of allocation,
> or of reallocation. It is the problem of how to describe (address)
> the (re)allocation in an efficient manner.
In C this can be done using an array of pointers to dynamically
(or statically) allocated memory. The implementation should
be reasonably efficient, though that assumes some locality of reference.
I would think that Fortran pointers could be used similarly, but
someone else will have to write about that.
> From the way in which Richard described pointer descriptors, I infer
> array descriptors must also contain the same information. So, what I
> ask is doable by generalizing these descriptors into linked lists (or
> a similar structure), but that is definitely a performance disaster
> and very non-trivial.
Linked lists work very well for applications that address the data
sequentially, and should perform well. For example, a text editor
needs to store the file data in memory, it is often done as a linked
list with a list entry for each line, or maybe for a group of lines.
A search function then goes down the list and searches each line,
a nice fast loop. (Assuming that the search will be done in any
case.)
> I see that much. So, the solution to the
> problem seems to lie in how to accurately describe non-contiguous
> sections of memory without resorting to something as complicated as a
> linked list.
Now, if you want random access to the data a linked list is not
good. That is what arrays are for.
> A special case solution could be a way to describe that you wish a new
> allocation of memory to follow the same allocation pattern from the
> base address of a currently allocated element. This would allow you
> to change the descriptor so that it knows the extent of the new space.
> Is this how move_alloc works?
Can you do an array of pointers to ALLOCATEd arrays?
-- glen
- Next message: Gordon Sande: "Re: INCLUDE file"
- Previous message: Richard Maine: "Re: Use of subroutines"
- In reply to: Ed Wells: "Re: appending elements to an ALLOCATABLE array"
- Next in thread: Richard Maine: "Re: appending elements to an ALLOCATABLE array"
- Reply: Richard Maine: "Re: appending elements to an ALLOCATABLE array"
- Reply: James Van Buskirk: "Re: appending elements to an ALLOCATABLE array"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
