Virtual inheritance problem while adding public member function to LES SGS Model
I have a really strange programming issue concerning virtual inheritance.
What I want to do:
What I basically did to achieve this goal:
tmp<volScalarField> myCoolFunction() // implementation file
My code compiles and seems to make sense from a programming point of view, if I got virtual inheritance correctly.
However: When I call my new function with turbulence->myCoolFunction() in my solver code, I do not get myCoolvolScalarField_. Interestingly, what happens instead is that some random(?) other function from compressible:turbulenceModel gets called (e.g. printing some LES SGS model coefficients).
By changing the order of the functions in the compressible:turbulenceModel header file, I can influence, which function from compressible::turbulenceModel gets called (so it is not that random at all), which means that the order of functions header file seems to matter! This is weird and doesn't make sense!
Anyhow, I can't call my function, also after having done some fancy reordering.
After a long while of googling without any useful results, I found that the construction of the virtual tables for the involved classes can produce the behavior I experienced, caused by peculiarities of some compilers. I run OpenSuse 12.1 and my compiler is gcc 4.6.2. I still use OpenFOAM 2.1.1.
What I would like to know is:
I would be very happy about any advice or hint!
I also tried to trick the virtual function table and added a couple of other dummy functions and put my actual function in between. Unfortunately, without success.
Furthermore, I added some dummy function input parameter (e.g. bool dummy), with the same idea in mind, again without success.
This is really weird and doesn't make any sense to me.
I suppose that myCoolVolScalarField is a volScalarField, so why do you return it as a tmp<volScalarField>?
Try do the following instead (using a reference):
virtual tmp<volScalarField> alphaEff() const = 0;
.. which is why I return a tmp<volScalarField>
I tried your solution, unfortunately, it does not solve my problem. I still get the same behavior (call of some other function in turbulenceModel).
I solved the problem:
It wasn't a programming issue, but basically a conflict between parts of our OpenFOAM being compiled on a server with a slighty different architecture. My locally compiled solver and libraries accessed libraries from the server, which is the root cause for my problem.
By compiling a local version on my machine, I got a consistently compiled OpenFOAM, and my weird error is gone.
Lesson learned: Either keep your architecture PC<-->server the same or compile everything on the machine, where you want to run your code.
|All times are GMT -4. The time now is 11:33.|