Hi Tobi,
I have a class that derives from singlePhaseTransportModel class.
Inside this class is a pointer to viscosity model. This pointer was private and now I changed it into protected to be able to use it. So I have an access to viscosity model and nu is calculated inside helium viscosity model class as shown in my previous post.

Okay, and how do you access the function? I mean, you should have something like that somewhere:

Actually I am interested in that line you should have somewhere (I guess in another form).

yes it is inside singlePhaseTransportModel
you can see it in doxygen. I changed only private to protected for viscosityModelPtr_.

Why are you asking?

Hi, actually I ment something different but it does not matter. I guess I know the answer to your question:

This code should be not working based on the fact that the object nu will be destroyed after the return statement. The returned tmp<> pointer points to a non-allocated memory address and thus you should get a run time error. However, your second example is working because you are returning the object returned by the max() function. The max() function will build a tmp<> object that will not be destroyed and thus, the object survives after returning.


To get your first approach running, this should be done:

Here, you build the tmp object which knows how many pointers point on the object. If you return it, you have to store the returned object in a tmp<> object again, in order to keep the object alive. After the end of calcNu() is reached, the returned tmp<> object survives and you should not get an run time error.

I hope I formulated it in a good way :) ...

This will work:
This will fail:

Hi Tobi,
Thank you very much for explanation, now it is clear for me.

Unfortunately I still have an error with nuEff() function.
This function is run in the line
in the UEqn.H. I have this error now
It results from that nuEff = nut() + nu() and nut() is size of zero and I do not know why.

There are too less information on what you changed. So it is not possible to give any advice, sorry.

Ok I found the origin of the error. I had the code in UEqn.H
If I comment the line
everything works well, but I do not know why???

How did you define your object nut. Can you give the definition of that object? And where do you use nut afterwards?

nut definition in createFields.H:

and I do not use it before line nut = turbulence->nut();

This cannot work because turbulence->nut() will return a tmp<> object which will be destoyed in your case :). So build your own field such as:

then you should get access to the field such as:
Or simply use:
without creating a volScalarField in the createFields.H

This should be corrected a little bit:
To my understanding it is essential that the object of volScalarField type is to be created in dynamic memory (on the heap) with operator new. If so, tmp can store a pointer to some place in dynamic memory which will stay untouched while tmp is returned from calcNu. On the other hand, when you initialize tmp with a pointer/reference to an automatic object (i.e., in simple words, you don't use operator new to create an object) tmp stores a pointer to a place in automatic memory (on the stack) which will be "erased" as soon as you return from calcNu and it yields undefinite behaviour.

Is is like that? I don't think so because the tmp<> class knows how much pointer points to the object. Therefore, if one returns the object such as:
while taking the returned pointer such as:
The object should be still alive, even if we leave the calcNu() function because a pointer still points onto the object. But out of the box I cannot proof that. Bruno told me once the following:

Any automatic object created within the body of a function can live untill the execution flow leaves the function. Then a destructor of the object is invoked rendering the object basically dead. A pointer to the automatic object can be incapsulated into a smart pointer object and returned from the function, but it will be useless anyway because the object it points to is dead. If you want an object to stay alive when the execution flow leaves the function you should create it with operator new as a dynamically allocated memory object.

Hmmm,.... actually without the new keyword it is not working at all based on the fact that the pointer has to point to an explicit allocated memory build by new. So you are right. Thanks for correcting me. For those who want to test it:

Hi, Tobias
Are you sure this piece of code issues an error? I didn't try it personally, but I believe it should be ok. myCalc returns a temporary object which is assigned to a const reference foo. And c++ rules make it possible: a constant reference can be "initialized" with a temporary object. The temporary object doesn't die right away, it's lifetime prolongates up to the constant reference lifetime. And they both will live untill the execution flow leaves the scope where the constant reference was defined. This code might not work for one reason though: myCalc returns tmp and foo expects volScalarField, I am not sure tmp can "converts" to volScalarField implicitly. If you do the conversion explicitly (with operator()) it should work like a breeze:

Hi,

yes it will give an runtime error. If one test the above code, the error appears. I was struggling about that in my openComfort library too because here I need access to the nut field which comes from the turbulence model. Right at the beginning I did this one:
However, this code failed always. Therefore, I replaced it with a copy operator which worked (obviously):
I was not happy about copying the object and asked Bruno. He gave me the explanation, that we have to keep a object of the tmp<> class alive by doing that:
Otherwise the object returned by the nut() function will be destroyed. You might be right that it will work with smart pointers like the auto_ptr in c++ but with the FOAM tmp<> class actually not (tested it).

Hopefully I could test it tomorrow and then get back to this thread.

I played around with the code and have to confirm that
fails at runtime. You have to use a pair of round brackets at the end of this expression to obtain (a reference to) volScalarField out of tmp. Otherwise it won't even compile let alone run.

Hmmm.... :/
Sure, it is obvious now.
After the operator () we have access to the object and can take the reference. My way was wrong. Should think more before I reply.

As always Sergei. Good point. Thanks for sharing.

Hi Tobi and Zeppo
Thank you guys for explanation all of these things and help. I solved my problem mentioned in #25.
It was caused by the bed use of tmp object.

I fixed the code according Zeppo solution as in the citation.
Also I added this line according to Tobi:
Thank's for sharing :)