CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM (
-   -   How to deal with fields of unknown type (

kar May 20, 2008 09:27

Hello, maybe you can sugges

maybe you can suggest a good solution for this problem: let F be an array of names and pointers (void*) to fields like volScalarField, surfaceVectorField etc; when adding a new entry to F, pointer type should be somehow memorised such a way, that it is as easy as possible to deal with that actual type of field later through pointer.

For example, I could use

volScalarField& f;
string typeName__ = f.type();,

but that means, whenever I need to do something, I need to build a ton of switches depending on typeName__. That is bad. Especially if I know, there is type() for each pointer...

A template solution?

kar May 20, 2008 10:24

And one more thing worth to me
And one more thing worth to mention:
if template function is in *.so, where it is not called, it simply is not defined for an external function call. That takes dirty work-around...
I would appreciate some words of wisdom here.

gschaider May 20, 2008 13:21

Hi Karlis! (Somebody of the
Hi Karlis!

(Somebody of the people with real knowledge: please correct me if I'm talking nonsense)

- your example doesn't make sense, because once f is a reference to volScalarField you already now what f.type() will be. The only common parent-class for all GeometricFields is IOobject where you can achieve something similar with f.headerClassName()
- I think what you are looking for is runtime polymorphism. The problem is that templates are "compile time" polymorph (in other words the same pointer can not point on a volScalarField and a volVectorField AND know that they are some kind of GeometricField
- the best solution is using templated functions/methods, Have a look at the sources for reconstructPar, how something like that is done (don'T know what you're trying to do)


eugene May 20, 2008 13:21

There is already a mechanism t
There is already a mechanism that handles all eligible objects as regIOobjects instead of their own types. Check the store() member functions in regIOobject and the lookup functions in objectRegistry to see how it is done.

kar May 20, 2008 15:33

Ok, thank you, this info can b
Ok, thank you, this info can be useful too.
Looks like I wanted to squeeze too much out of g++ compiler + wasn't sure what I want.
What is done here is writing a class for easy dynamic field management, that also reads and registers fields by writing far less C++ code, once that class is written.

One thing I still want to know about this: is it possible to write and compile library with function or class templates without ever calling any of them within library code, but using afterwards?

gschaider May 20, 2008 16:11

Answer: Yes, it is possible, B
Answer: Yes, it is possible, BUT you've got to instantiate them explicitly in one of the object files of the library:

kar May 20, 2008 16:32

So one should use: template
So one should use:

template int min<int> (int, int); //function template instantiation
template class vector<string> //class template explicit instantiation

I appreciate.

kar May 22, 2008 06:17

But may I extend the topic abo
But may I extend the topic about runtime function calls to classes of varying implementation?
Basic idea is: there exist N>1 classes with common functions of identical names, which are differently implemented. How to call those functions, if classes aren't the same and pointer selection happens in runtime?

All times are GMT -4. The time now is 04:14.