-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add deallocate/reallocate option to ALLOCATE #61
Comments
@rweed actually this would be very useful. I often have code like this to run some convergence study: do i = 1, max_iter
n = n * 2
allocate(A(n), B(n), C(n), ...)
....
deallocate(A, B, C)
end do So it would get reduced to just this: do i = 1, max_iter
n = n * 2
allocate(A(n), B(n), C(n), ..., reallocate=.true.)
....
end do That way one does not need to repeat 10 arrays in the |
@certik wrote:
Here's a recent thread at comp.lang.fortran forum on this, perhaps the same as what @rweed mentioned. I wrote in that thread, "what interested users can do is to make a case for enhancements such as this in the standard and put a together a proposal paper for submission with one or more contacts listed at the WG5 Fortran website. GitHub is a good platform for users to group together and collaborate to capture their needs, collect use cases, and summarize what is of interest for an enhancement or addition to the language. The standards committee can best work on the response: either No, or if at all yes, as to how and when!" Mega Kudos to @certik and @zjibben for making GitHub happen! Now, if only WG5 Fortran can follow "common sense" which will be to not proceed with a "frozen" work-list with J3 on Fortran 202X revision! Rather they can follow a somewhat open approach which allows work to proceed on many good ideas based of course on some objective, initial screening. Then, in this day and age of modern collaborative platforms such as GitHub and amazing multitasking abilities of interested and multi-talented folks, considerable progress can occur online in parallel and near-ready features for official standard publication can be developed. so much so that committee can increasingly be in a critical review mode, to cross-check and resend for correction or refine work, thereby saving themselves so much time. What is needed mostly are some guidelines or criteria - clearer the better - on what to do or not do in terms of additions/changes to the Fortran standard. Delegate to develop faster is what the committee can best do for Fortran. Many, many ideas like the one with ALLOCATE statement in this thread can then be absorbed into the next revision. It is then too bad something like this will have to wait for Fortran 202Y. |
I would like to add that modifications like this fit my criterion for things that the committee should give priority to above adding new capabilities that will take much longer to develop and implement. Namely,
Therefore (and this this touches on issue #36) I would like to see the committee priortize their work along these lines.
I would move as suggested to a 3 year development cycle with the first 1.5 years addressing an agreed upon number of priority 1 items. This could be released as an interim standard (a TS or TR) some time between year 1 and 2 and allow the developers to implement them prior to the release of the full standard. Concurrently, Priority 2 items can be developed over the full 3 year cycle. Priority 3 items could be pushed into a five year cycle I strongly agree with @FortranFan that the current development process is too inflexible and doesn't allow for items that have an obviously short development and implementation cycle to be added in a specified window after the initial feature set for each standard revision is agreed upon |
@FortranFan, @rweed thanks for the feedback. I think we are all in full agreement how this should work. I just posted in a similar spirit at https://groups.google.com/d/msg/comp.lang.fortran/dFenjU25o9k/TaLSwNS3DQAJ. Now, in order to move forward from here, can you please both help me in the issue #26 to formalize what you just wrote above? We need two documents:
It's important however to have this written up in documents, and truly think all the arguments out (let's collaborate on that), so that when committee members read it, they can say: "These are really good points, why don't we try that?". Such a document also gives me and many others on the committee something to bring up and collect feedback on. (As opposed to just a GitHub issue.) If you are for it, why don't you just post a draft of such documents into #26 as comments, and then we'll create a PR and create an actual document, once we can agree on the wording. |
Why not just make this the default behavior of |
I think I want this behavior while developing, to catch double allocation bugs. I think the user should specifically say when reallocation is wanted, otherwise it should give an error. |
This idea was originally proposed a few months back on C.L.F. b someone else so I'm echoing it here
Add an optional deallocate/reallocate logical argument to ALLOCATE to tell it to check allocation status of any variable in its allocate list and deallocate it prior to allocating to a new size if it is already allocated.
Example
Instead of having to code
If (ALLOCATED(A)) DEALLOCATE(A)
ALLOCATE(A(N))
do
ALLOCATE(A(N), REALLOCATE=.TRUE.) or
ALLOCATE(A(N), DEALLOCATE=.TRUE.) ! either syntax works for me
Basically you are telling the compiler to check allocation status and instead of issueing an error (absent the status variable), do the deallocation for me and then reallocate.
This can save several lines of code if you have a lot of dynamic arrays that you need to periodically resize
The text was updated successfully, but these errors were encountered: