FINAL routines in Fortran 2003

[NotThatItMatters]

I am having some trouble understanding the need for and use of FINAL routines in Fortran 2003.  I have a TYPE (or CLASS) which has a second TYPE extending it.  The second TYPE and the first TYPE each have FINAL routines.  I explicitly CALL the FINAL routine for the second TYPE.  According to the F2003 standard, should it be the case that the first FINAL routine gets called as well?  I can run the application in debug and put a break in the first FINAL routine and note it is never reached.

Now here is the heart of the matter.  What is the use of the FINAL routine?  In the deep dark past of which I am accustomed, final-like routines were mainly used to prevent memory leaks.  The current Fortran standard seems to have memory "management" which does not explicitly require a DEALLOCATE statement for every ALLOCATE.  So, what is the use of FINAL?

[FortranFan]

Refer to chapter 14 in Modern Fortran Explained, the book by Metcalf et al.  Think of when the derived type makes use of some resources (open and read files, databases, etc.) and/or has pointer components.  Finalization can help "clean" things up in such situations, as explained in the book.  If all you have are allocatable components, you most likely don't need to worry about finalization.  The standard states specific circumstances under which finalization would take place.  Your situation perhaps is not one among them.  You'd need to consult the standard and clarify for yourself.  If you feel the compiler is not doing what the standard says should happen, then please report it with supporting details.  The compiler is most likely not the final authority yet on a feature like this!

[NotThatItMatters]

I am a little meticulous in that I have been taught that every ALLOCATE deserves a DEALLOCATE.  I built my construct as basically a STATIC CLASS because that is its use in code: one set of arrays to be used over and over.  The second child CLASS EXTENDS the original one by adding some additional static arrays.  The CLASS structure was needed simply for this reason: no need to duplicate the original CLASS if all you are doing is extending it.  And, no, this is not a linked list so there is no tree structure or other here.

By the way, "Modern Fortran Explained" by Metcalf et al. is sitting right here.  Maybe if I could read I might have answered my own question.

[IanH · Accepted solution]

 I explicitly CALL the FINAL routine for the second TYPE.  According to the F2003 standard, should it be the case that the first FINAL routine gets called as well?

You shouldn't be calling the final procedure explciitly (unless you are doing something a little bizarre), the compiler will arrange to call it for you when, informally, the value of a variable of the relevant type is about to cease to exist (as FortranFan notes, the exact set of conditions are in the standard - I didn't find a particularly useful definition in the intel compiler documentation).  When an entity is finalized by the compiler in such a way, you will get the hierarchical invocation of finalizers (if a matching finalizer exists in the type) for components of the type, which includes the parent component of an object of extended type, after finalizing (if a matching finalizer exists) the object itself.

Every allocate of a pointer needs a matching deallocate.  Allocatable variables (and/including allocatable components) are automatically deallocated when they go out of scope (or in some other situations, such as association with an INTENT(OUT) dummy argument), and only need a "matching" deallocate when you want to force the end of their existence at a particular point in the sequence of execution ("matching" doesn't particularly apply here anyway in quotes, because there are ways in which an allocatable variable can be allocated without an ALLOCATE statement).

[LRaim]

Since I started with Fortran IV I am a bit conservative with respect to new features (though I am currently using also C++), so it is interesting to know new features from this site posts.

This is a question for Intel people:

I am using Intel Fortran Compiler 15 and I have searched compiler reference documentation for the FINAL (keyword or statement) but there is no description in the "A to Z reference" section. 

Where can I find a description of what FINAL does ?

Regards

[IanH]

The only description I could when I looked before was under "Type Bound Procedures" - https://software.intel.com/en-us/node/525432#34673684-C86E-4E48-AE56-3EE810730A15 for v15

[Arjen_Markus]

The page mentions the possibility to define several routines as FINAL, but it does not say what the effect is. Will they all be called for finalisation? If so, in what order? If not, which one?

[Kevin_D_Intel]

I thought perhaps IanH’s reply #4 answered your questions, however, I have to defer to those with more knowledge of this language feature to assist.

Please let me know if there are specific documentation enhancements that I can forward to Development regarding this topic. I’m not sure it makes sense to list the individual aspects of the type-bound-procedure binding statement PROCEDURE in the A-Z reference.

[NotThatItMatters]

Perhaps some generic need of a FINAL procedure might be documented.  I am being old-school here, but the need for FINAL procedures in the past was absolutely necessary with CLASS structures which were self-referential.  This included linked lists or tree structures that had "next" pointers which referred to other items in the tree or list.  In these cases, memory allocation was split across numerous objects and the freeing of this memory required the user to traverse the tree to the leaves first and free up the memory and then proceed "downward."

[IanH]

If you are using pointer components and are emulating value semantics with those components, then finalizers have something to offer.  By this I mean something like:

TYPE :: t
  ! An object of this type may have child objects that are 
  ! of the same type.  When the parent object is destroyed 
  ! we want the child object to also be destroyed.  When 
  ! the parent object is copied, we also want to create a copy 
  ! of the child object.
  TYPE(t), POINTER :: child => NULL()
END TYPE t

TYPE(t), ALLOCATABLE :: a
ALLOCATE(a)
! a has a child object.
ALLOCATE(a%child)   ! ptr allocation
...
! We decide we no longer want `a` and its children.
DEALLOCATE(a)       ! <-- we want automatic DEALLOCATE(a%child) here

I suspect the above is the sort of thing you are referring to.  You could use a finalizer to achieve that automatic deallocation of a%child (and so on, down the hierarchy).

TYPE :: t
  TYPE(t), POINTER :: child => NULL()
CONTAINS
  FINAL :: t_final
END TYPE t

...

IMPURE ELEMENTAL SUBROUTINE t_final(object)
  TYPE(t), INTENT(INOUT) :: object
  IF (ASSOCIATED(t%child)) DEALLOCATE(t%child)
END SUBROUTINE t_final

(In other cases, pointer components are just used as references - the object with the pointer component doesn't "own" the thing being pointed at - when the object with the pointer component goes away the thing being pointed at can continue to live on.)

When Fortran 2008 support is complete, there will be perhaps less need to use pointer components with value semantics, because a type can contain allocatable components of the same type (i.e. what you can currently only do with pointers).  When you deallocate an object, allocatable components of an object are automatically deallocated.

[FortranFan]

Kevin Davis (Intel) wrote:

..

Please let me know if there are specific documentation enhancements that I can forward to Development regarding this topic. I’m not sure it makes sense to list the individual aspects of the type-bound-procedure binding statement PROCEDURE in the A-Z reference.

Kevin,

Instead of a specific documentation enhancement, I suggest Intel Fortran team consider a complete revamp of the Fortran documentation.  Honestly there are many, many sections of the documentation that I find absolutely poor, to say the least.  From a high-level point-of-view, it appears to me there are 3 large aspects to Intel Fortran: 1) standard Fortran features from various standard revisions (all  the way to Fortran 2015), 2) extensions including OpenMP, vectorization, OS APIs such as Windows programming, QuickWin, etc.,; these are probably aspects that your management might view as bringing some competitive advantage to Intel. and 3) support of legacy aspects including deleted features (e.g., assigned GO TO statements) in a current standard, and  I'd suggest some restructuring that takes these 3 aspects into consideration.

For 1) i.e., standard aspects, I wish Intel can work something out with standard bodies (ISO/WG5/J3) to include the exact same information that is in the standard.  If one is looking up a standard function, e.g., IS_IOSTAT_END, it'll be great if one sees exactly what the standard says on it within the Intel documentation itself.  And it will be truly wonderful for any feature, say FINAL keyword aspect of this thread, Intel documentation were to offer some kind of links to all relevant sections in the current Fortran standard on that aspect.  If something like could be worked out, then Intel needn't really have "writers" to "reinvent the wheel" for standard stuff, simply provide links to (or regurgitate text from) standards documentation.  I don't know if there are copyright-type of restrictions with referencing the standard in Intel Fortran documentation, but if there are, I suggest Intel reps on Fortran committee use the full force of Intel brand and the voice of its customers to change the situation!  Now, some of your experts such as Dr Fortran may have extra commentary on particular features e.g., SUBMODULEs and it'll be very valuable if those are "linked" in with the documentation too.

On 2) i.e., extensions on vectorization, Windows (or Linux/MAC) programming, OpenMP, etc.., Intel's customers can benefit from improved and more illustrative text in documentation with more examples including worked out instances showing the extent of benefits from these features.  In situ links to tutorials, other education material, etc. will be valuable too e.g., if I'm looking up $DIR VECTOR attribute, right at the bottom to a link of a sample that makes use of that feature.

On 3) i.e.. the legacy aspects, Intel should strive to a) provide a good level of detail and examples here also and b) suggest how things can be done using the current standard.  As much as I'd like many of the legacy features to disappear from all the code out there altogether (and even though I strive to port/upgrade as much code as I'm able to), the code will remain in existence for a long time and younger and younger folks will need to support such code at some point.  Since Intel compiler usually continues to support such legacy features for extensive periods (possibly for ever), having proper documentation with useful examples and instructions on how to port to newer ways can be a competitive advantage 

Thanks for your attention,

[Kevin_D_Intel]

Wow, thank you FortranFan for the comprehensive feedback. I will share this with the Fortran Development and Documentation teams. Hopefully we can incorporate some your ideas/advice into future releases and improve the quality of our documentation.

[Kevin_D_Intel]

I gathered the feedback on the documentation and provided this to the Documentation and Development teams. Thank you for your candid feedback.

(DPD200376246 - FortranFan feedback/suggestions)
(DPD200376248 - Improvements specific to FINAL)

[NotThatItMatters]

Thank you.  I have updated my use of FINAL routines in my code with the help of the many comments.  As I have read I have recognized it is not only myself with limited understanding of the concept.  I guess all we can hope to do is learn.

[Kevin_D_Intel]

The internal tracking ids noted earlier have been closed noting that related documentation improvements will appear in our next major release (next year).

Related to DPD200376246, the Documentation writers said we cannot quote from or link to the Fortran Standards because of copyrights so additional messages will be included in the top-level topics about how to find the Standards.  In terms of document organization, they said no extreme reorganization was planned at this time but they are reviewing all the feedback to see if there are other improvements that can be made.