[agustinvo]

Hi,


I know that this topic has been discussed previously:

• tmp - stands for 'true macro pain'?
  

But it still not clear, at least ceraint aspects, for me. I am not a C++ developer but a OpenFOAM user that deals with turbulence model implementations. I had at the university a course where pointers were introduced (15 years ago), so please don't be so acid me if I don't get the idea inmediately. These are my ideas with respect tmp fields

• tmp fields/matrices: we use them when we want (or need) to clear memory, because these fields/matrices are large. This is what simpleFoam does with UEqn as a tmp<fvVectorMatrix>. We generate tFields, tEqns... to indicate that are tmp objects.
  

  tmp<fvVectorMatrix> tUEqn
      (
          fvm::div(phi, U)
        + MRF.DDt(U)
        + turbulence->divDevSigma(U)
       ==
          fvModels.source(U)
      );

• Once this tmp<fvVectorMatrix> is defined, where do we see the memory usage impact of this method? Only when clearing tUEqn?
• Is it needed to clear all the tFields, tEqns... in the code? I have heard a bit abut scopes using curly braces (this is what), and AFAIK if I define a variable inside a scope they are destroyed (cleared) once the program goes out of the scope. If I use these tFields inside a scope, am I clearing them automatically? If I clear, for example, tUEqn, what happens with UEqn? Does it stays in memory?
• What does tUEqn.ref() means? As far as I understood, when we do
  

  fvVectorMatrix& UEqn = tUEqn.ref();

  we are pointing to the tUEqn.
  Why can't I use tUEqn directly? If UEqn is defined to point to the tUEqn, I suppose you have a reference to a pointer, but if the original data is available, I don't see the point of creating this intermediate object.

Thank you for your help!

[Santiago]

tmp<> is an pre-STL version of a pointer Handle or weak_ptr<>. Is a means of moving (as opposed to copying) data across function calls while avoiding registering said data in the time selection mechanism (Factory) in FOAM. You use it when you don't want to duplicate data, for short lived templated datatypes that don't need be registered in the time selection mechanism, or when you are not sure of the lifetime of the original data (a reference can be deallocated, and become invalid, a tmp guarantees the lifetime of the underlying object by keeping a count).

There is another use: geometricFields (and many other things in FOAM) have no null-constructor. You may want to declare a tmp<geometricField<...> > in one scope and DEFINE it in some other scope, for example.

[Santiago]

ref() is a construct in new versions of FOAM: it returns a reference of what is inside the tmp, so you don't have to de-reference the tmp everytime you do operations on it. Earlier versions of FOAM used operator() for returning the reference.

BTW, the code you show has little context so it is difficult to say why tmp was used there.

[Santiago]

Don't want to be acid but the rest of the questions refer to basic C/C++ (scopes, lifetime, what is memory) so ill refer you to "accelerated c++" for details.

[agustinvo]

Thank you for your comments! I will check that reference about C++. I hope it helps me to get the idea behind using these concepts.

[olesen]

Need to comment that there is yet another reason for the tmp - it can either hold a managed pointer (somewhat like a mix of unique_ptr and shared_ptr) but it can also hold a reference to an object (somewhat like std reference_wrapper, but can be nullptr initialized).
This duality is be particularly convenient.
There is also a refPtr wrapper that is similar in many ways to tmp but does not require object to have embedded reference counting.