Given that the SWIG-generated Epetra_Object type doesn't have associated operators, I probably should have written the question on an extended type such as

type, extends(Epetra_Object) :: my_object

contains

   procedure :: add

   generic :: operator(+)=>add

end type

Then essentially the same question applies to the Epetra_Object parent component that is automatically a part of any my_object variable.  If the user is responsible for explicitly invoking the public "release" binding that Epetra_Object provides, the most natural place to do that is inside the "add" procedure above, but how does the add procedure know whether it's safe to destroy its arguments?  

Alternatively, to ask a question that is fundamentally the same but avoids the operator syntax, the same statement could be written as

a = add( f(b), g(c) )

and all the same questions apply.

Will users be allowed to extend ForTrilinos objects?  If so, will they be required to write final subroutines for all extended types?  That wouldn't be too onerous, but it would have to be made clear to users and it would differ from what is probably the most common experience in writing Fortran-only code, wherein the need for final subroutines is significantly less.  There are large Fortran projects that use derived types and OOP but never need to write final subroutines.

Your question seem to imply you are calling Fortran subroutines from C++ main program. If this is your intent then all the Fortran objects will be treated as local and will be automatically destroyed after the result is returned to C++.

Usually I think of  Fortran main program calling C++ libraries in which the Fortran objects are defaulted as global, except while instantiated as local in one of the C++ routines. 

With "the C interoperability features of the Fortran 2003 standard, an automated memory management architecture is embedded into each ForTrilinos object" at the time of creation. There are so many packages and releases using Trilinos that you would probably need to refer to documentation specific to your release or to the user group for that release to get an exact answer for your purpose.

Building with some early versions "requires setting flags that work

    around two missing compiler features: support for final subroutines and

    support for deferred-length character components. A sample script that sets

    the aforementioned flags is in :

    Trilinos/sampleScripts/mac-fortrilinos-gcc47-openmpi-debug and

    Trilinos/sampleScripts/mac-fortrilinos-gcc47-serial for mpi and serial

    builds respectively."  Users who build with early versions "should adopt two

    practices to prevent memory leaks:

      1. Construct ForTrilinos objects using the ForTrilinos constructor

         subroutines (do not use ForTrilinos constructor functions).

      2. Manually destroy all constructed ForTrilinos objects using by

         invoking the object's 'force_finalize' type-bound procedure."

I find a lot of help by contacting the related users group. 

Thanks for the reply. I was referring to what happens when Trilinos objects are instantiated in C++ by calls made into Trilinos from Fortran (which could be a Fortran main program). Where was the quoted text "the C interoperability features of..." from?  It sounds like language from the previous incarnation of ForTrilinos, which is the current master branch of ForTrilinos on GitHub.  I don't think that language would apply to the new incarnation of ForTrilinos, which is on the "develop" branch. 

At the bottom of my question, researchgate inserts the text 

"Asked in project:

ForTrilinos..." 

so I assumed this is posting to the ForTrilinos group.  My apologies if this is not the appropriate place to post the question.  I don't know that there are current users of ForTrilinos.  The master branch (the development of which I led a decade ago) has been dormant for 5 years and the new "develop" branch is just getting underway. 

Damian,

First of all, thank you for posting your question. These questions would certainly need to be addressed. I'm currently lacking the knowledge to properly assess the situatuation. So let me ask you a few things:

1. What are the limitations of the design of the C++/Fortran object interaction in the original version of ForTrilinos? Are there alternatives?

2. I'm less concerned about "How will the Fortran code get notified if C++ destroys the object?" as I think that ForTrilinos would hold a referenced counter pointer to C++ class. So if I understand the process, we would destroy it only during the destruction of the Fortran class.

P.S. Sorry for replying late, I was pretty sure I already posted but it did not appear.

Regarding 1, it's probably best to read the papers we wrote on the subject:

http://dx.doi.org/10.1109/MCSE.2012.33

http://dl.acm.org/citation.cfm?doid=1985782.1985786

Email me if you have trouble accessing these and I'll reply with PDF's.  We were also awarded a related patent, which the Sandia intellectual property staff assured me posed no problems with using the algorithm in ForTrilinos:

http://patents.justia.com/patent/20120047496

Regarding 2, I'll be very curious to see the details of what you're describing.  When you write "a referenced counter pointer to C++ class," I assume assume you mean "a reference-counted pointer..."  The SWIG-generated forepetra.f90 file contains a Epetra_Object derived type with a type(c_ptr) component named "ptr".   Is this the reference-counted pointer to which you're referring?  If so, are you referring to a reference-counting scheme in Fortran or to the reference-counting scheme that already exists in C++?  If the reference counting scheme happens in Fortran, then it will be interesting to see how one can be generated with SWIG.  I don't see anything in the current SWIG output that suggests there's reference-counting happening.  If the only reference counting happens in C++, then I'm not aware of schemes to avoid dangling pointers and memory leaks other than the scheme we developed.  

It would probably be worthwhile to try compiling code like what is written in the clarification that I posted just after posting my initial question. Run the resulting executable through valfgrind and check for memory leaks. And also consider whether there are scenarios that could lead to dangling pointers. If C++ destroys an object, I don't think that automatically nullifies any type(c_ptr) pointers holding the C address of the C++ object.

Damian