# SOURCEd allocation for dynamic array handling **URL:** \ **Category:** Help\ **Created:** [June 23, 2022, 8:42am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823 "2022-06-23T08:42:53Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [June 23, 2022, 8:42am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/1 "2022-06-23T08:42:53Z")
I’m trying to find the most compact/clear way to reallocate an array to a different size, keeping both boilerplate and allocations to a minimum and am looking at SOURCEd allocation. In the example, with `gfortran`: - if the new array is longer, all data is copied from a, and the trailing elements are not initialized (nice) - if the new array is shorter, sourcing it to a longer array leads to a segfault. ```fortran program compact_resize implicit none integer :: i,j integer, allocatable :: a(:),longer(:),shorter(:) a = [(i,i=1,10)] print *, 'a=',a ! works allocate(longer(20), source = a) print *, 'b=',longer ! segfault allocate(shorter(5), source = a) print *, 'c=',shorter end program compact_resize ``` Is what I’m doing violating any standards? the [Intel documentation](https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/a-to-z-reference/a-to-b/allocate-statement.html) says " If object is an array, s-spec must appear and the number of s-specs must equal the rank of object, or source-expr must appear and have the same rank as object and the shape of object is that of source-expr". In other words, it seems like the option of BOTH specifying the size of the array and an array source-expr is not considered. ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [June 23, 2022, 9:03am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/2 "2022-06-23T09:03:11Z")
On Metcalf/Reid/Cohen it states that “if allocation is for an array, source-expr may be an array of the same rank, otherwise source-expr must be scalar”. also “because the bounds and shape of the allocated item are not taken from the source, making a clone of an array has to be done [by specifying its bounds]”, like ```fortran allocate(a(lbound(b,1):ubound(b,1)), source = b) ``` So apparently there’s a constraint on the rank, but not on their size, gfortran is doing it right, but of course it’s overflowing the copy when the new array is shorter than the former… ---
**Author:** ![Sideboard](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sideboard/32/779_2.png) [@Sideboard](https://fortran-lang.discourse.group/u/Sideboard)\ **Post date:** [June 23, 2022, 9:21am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/3 "2022-06-23T09:21:21Z")
If you know they are shorter, you could apply bounds to the source: ```auto allocate(shorter(5), source = a[:5]) ``` Or more general: ```auto allocate(shorter(new_size), source = a[:min(new_size, size(a))]) ``` ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [June 23, 2022, 10:28am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/4 "2022-06-23T10:28:17Z")
This program demonstrates an array constructor with an implied do loop and also `reshape` with `pad` to grow an array: ```auto program main implicit none real, allocatable :: x(:), y(:), z(:) integer :: i x = [10.0, 20.0] y = [x, (0.0,i=1,3)] z = reshape(x, shape=[5], pad=[0.0]) print "(*(f4.1,1x))", y,z end program main ! output: 10.0 20.0 0.0 0.0 0.0 10.0 20.0 0.0 0.0 0.0 ``` I have [tweeted](https://github.com/Beliavsky/FortranTip) about using `move_alloc` to do so more efficiently. ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [June 23, 2022, 12:52pm UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/5 "2022-06-23T12:52:00Z")
Nice alternatives, thank you both. So I’m guessing the best option is still the sourced allocation, but unfortunately, more bound checking lines will always be necessary like ```fortran pure subroutine resize(array,newsize) type(mytype), intent(inout), allocatable :: array(:) integer, intent(in) :: newsize integer :: copysize type(mytype), allocatable :: tmp(:) copysize = min(newsize,merge(ubound(array,1),0,allocated(array)) allocate(tmp(newsize),source=array(:copysize)) call move_alloc(from=tmp,to=array) end subroutine resize ``` ---
**Author:** ![ricriv](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@ricriv](https://fortran-lang.discourse.group/u/ricriv)\ **Post date:** [April 26, 2024, 8:37am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/6 "2024-04-26T08:37:01Z")
Hi Federico, I was looking for how to resize an array, and I found this thread. At first I thought that using `source` was a neat solution, but then I started wondering: where will this memory go? Maybe at the beginning of the new array? At its end? Somewhere in the middle? I might be wrong, but this sounds like undefined behavior. Then I found [this StackOverlow answer](https://stackoverflow.com/a/33911616/3676517), where the author says that it’s not allowed to have a source smaller than the new array. Moving on, I checked [the Intel documentation](https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2024-1/allocate-statement.html), where they only require that the two arrays have the same rank. And finally I checked the draft of Fortran 2023 standard, where in 9.7.1.1-3 it’s written that source-expr shall not depend on the bounds of any allocate-object in that statement. What do you think about it? ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [April 26, 2024, 10:31am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/7 "2024-04-26T10:31:47Z")
> [@Beliavsky](#): > > `z = reshape(x, shape=[5], pad=[0.0])` I think it’s pretty clear that `source`d allocation from a different-size array is non standard conforming. So, to achieve the one liner I was suggesting in the first place, @Beliavsky’s example is the way to go. But I’m not sure about the overall safety/speed of this approach. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [April 26, 2024, 10:39am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/8 "2024-04-26T10:39:30Z")
This is where [GitHub - PierUgit/enhanced-allocatables: Fortran allocatable arrays made resizable](https://github.com/PierUgit/enhanced-allocatables) would be useful (the code is non-standard, it’s just there to illustrate the added value of resizable arrays). ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [April 26, 2024, 7:07pm UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/9 "2024-04-26T19:07:33Z")
Unfortunately, the Fortran standard does not offer the much-desired flexibility with array resizing, refilling, rebinding, and rebinding + refilling (which by merging them, I call it rebilling). Frustrated with explaining user needs to the Fortran committee members (only to have the suggestions dismissed a day after with one stroke), a few years ago, we wrote four extensive multi-precision, multi-dimensional, fully generic modules specifically for the allocation tasks you described. These are: | Module | Functionality | | --- | --- | | [pm\_arrayRebill](https://www.cdslab.org/paramonte/fortran/2/namespacepm__arrayRebill) | This module contains procedures and generic interfaces for resizing allocatable arrays of various types, relocating their contents, and rebinding (re-indexing) their lower and upper bounds, and refilling the newly added elements. | | [pm\_arrayRebind](https://www.cdslab.org/paramonte/fortran/2/namespacepm__arrayRebind) | This module contains procedures and generic interfaces for resizing allocatable arrays of various types, relocating their contents and rebinding (re-indexing) their lower and upper bounds. | | [pm\_arrayRefill](https://www.cdslab.org/paramonte/fortran/2/namespacepm__arrayRefill) | This module contains procedures and generic interfaces for resizing allocatable arrays of various types, relocating their contents and filling the newly added elements with specific values. | | [pm\_arrayResize](https://www.cdslab.org/paramonte/fortran/2/namespacepm__arrayResize) | This module contains procedures and generic interfaces for resizing allocatable arrays of various types and relocating their contents, without initializing or filling the newly added elements with specific values. | It’s hard to exaggerate how useful and time-saving these modules have been in subsequent developments. We paid careful attention to the design of interfaces to ensure flexibility and performance simultaneously. If you want to try the [examples supplied with any of the above generic interfaces](https://github.com/cdslaborg/paramonte/tree/main/example/fortran) follow the [QuickStart](https://github.com/cdslaborg/paramonte/blob/main/QUICKSTART.md) instructions here and the extra build flag [exam](https://www.cdslab.org/paramonte/generic/latest/installation/install.config.md#exam) to enable the example build and run for the specific module. For example, ```bash ./install.sh --exam pm_arrayResize ``` If you try any of the modules, we would appreciate your feedback and suggestions for improvement. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [April 26, 2024, 7:27pm UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/10 "2024-04-26T19:27:20Z")
> [@shahmoradi](#): > > Unfortunately, the Fortran standard does not offer the much-desired flexibility with array resizing, refilling, rebinding, and rebinding + refilling. Frustrated with explaining user needs to the Fortran committee members (only to have the suggestions dismissed a day after with one stroke), a few years ago, Just about everyone that has had to deal with Fortran allocatable arrays since F90 has wanted an intrinsic procedure to resize/reallocate and a dynamically varying array (like C++ vector classes) etc. Like most folks I ended up writing my own but they are limited to just my use cases and don’t cover the entire spectrum of potential use cases. I think that you have summed up the frustration of that many of us have with the Committee. We have legitimate needs that aren’t addressed by the current standard that potentially impacts the entire spectrum of Fortran users but the Committee appears to spend its time implementing things that experience has shown are only beneficial to a handful of users (even though the Committee appears to think otherwise). My personal opinion is that this “write it yourself” attitude is one of the major reasons people have migrated to other languages. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [April 26, 2024, 7:49pm UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/11 "2024-04-26T19:49:51Z")
> [@rwmsu](#): > > Just about everyone that has had to deal with Fortran allocatable arrays since F90 has wanted an intrinsic procedure to resize/reallocate and a dynamically varying array (like C++ vector classes) etc. What is even more frustrating here is that implementing it both in the standard and in the compilers doesn’t look complicated: in my demo code, the C part that does the core of the job by manipulating the array descriptors is less than 100 lines. We could have the best of the Fortran arrays (multi-dimensions, arbitrary lower bounds…) and of the C++ vectors (resizeability…) at a little cost. It’s one or two orders below implementing a fully new type or a new data structure. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [April 27, 2024, 9:52am UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/12 "2024-04-27T09:52:45Z")
> [@rwmsu](#): > > Like most folks I ended up writing my own but they are limited to just my use cases and don’t cover the entire spectrum of potential use cases. And anyway it can’t cover the the entire spectrum: resizing an allocatable array without moving the content is not possible at all with a standard-conforming code. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [April 27, 2024, 1:39pm UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/13 "2024-04-27T13:39:38Z")
Yes. MOVE\_ALLOC is a useful feature in the context of the current standard but if you want to keep the current contents of an array you are forced to use a temporary which can have a potential big impact on performance. People forget that one of the things that saved C++ and made it viable as a language for scientific computing is the introduction of expression templates that provided the compiler with more opportunities to optimize away some of the temporaries needed for things like operator overloading as well as a dynamic polymorphism etc. I read somewhere that a lot of the performance problems in the early days of C++ (more so than the OOP constructs) was due to the compiler creating a lot of temporaries when it tried to overload operators. I think an intrinsic facility for reallocation etc would also remove the need for the creation of temporaries you still have to use with MOVE\_ALLOC. As I’ve stated in previous posts, if you don’t need save the contents of an array, the addition of an optional DEALLOCATE logical option to ALLOCATE that would tell the compiler to let ALLOCATE deallocate an existing array and resize it without throwing an error would go a long way to remove some of the frustration involved with just changing the size of an existing array. All current compilers will throw an error if you try to ALLOCATE an already allocated array without explicitly DEALLOCATEing it first. ie ```auto real, allocatable :: a(:) allocate(a(10)) allocate(a(20), DEALLOCATE=.TRUE.) ``` would not throw an error. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 27, 2024, 1:53pm UTC](https://fortran-lang.discourse.group/t/sourced-allocation-for-dynamic-array-handling/3823/14 "2024-04-27T13:53:03Z")
A related thread is [Do we need REALLOCATE?](https://fortran-lang.discourse.group/t/do-we-need-reallocate/1088) and issue is [Add deallocate/reallocate option to ALLOCATE · Issue #61 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/61).