[marupio]

Now that I'm working with templates, would someone be able to tell me the purpose of the "NoRepository" flag? I've been ignoring it until now, but I'm thinking I'm limiting the compatibility of my code.

[wyldckat]

Hi David,

I read something about this sometime ago... I did a search now here in the forum and picked up this thread: http://www.cfd-online.com/Forums/ope...epository.html - mmm, it doesn't say much, except for this:

Originally Posted by hjasak

Regarding the NoRepository stuff, you don't need to worry about it: it is to do with template instantiation mechanisms in C++.

OK, I didn't pick up on what I vaguely remember reading sometime ago. AFAIK and/or remember, if NoRepository is defined, it will include the respective .C file for the header it is enquiring in. In every case, the respective template .C file is not mentioned explicitly in the Make/files where the templates reside.

What this entails is the following scenario:

• The header is included whenever an application or library needs the template definitions.
• If the application/library doesn't link to the compiled target template, then the whole code for the template should be included.

After investigating a bit further, there doesn't seem to be a Repository situation... in other words, there doesn't seem to exist libraries that solely contain the instantiations of the templates...
So I can only assume that this is an optimization solution, along with respecting the coding standards defined for OpenFOAM, as well as similar to using inline functions/methods: keeping the template code objects close to their definitions will keep things nice and optimum.

Perhaps going back to OpenFOAM 1.0 or before that, we could figure out the transition period that lead to this conclusion...

Best regards,
Bruno

[wyldckat]

After brainstorming a bit more on this subject, as well as reading up on the subject, I'll write down my findings here.

The article "How To Organize Template Source Code" explains precisely the information we are looking for about templates. To sum up:

• Templates are sort-of like über-macros, which means that they must always be visible by the code that calls upon them. For example:

  #define SRCVERSION 1.7.x

  This definition must be put in the same C/CPP file or in a header included by the file that needs the information, or even defined by the compiler. This define cannot be accessed with an extern keyword, as we can with global variables.
• Nonetheless, there are two ways around this limitation:
  1. Create a library (or repository) that has instantiations of the templates. For example, if we needed lists of vectors or scalars:
     • We can have a master template for a generic list class;
     • Then have a library with multiple class definitions based on that template.
  2. Or use the keyword export, which wasn't supported in the past and may or may not be supported by some compilers nowadays.
• As explained in the FAQ at openfoamwiki.net, subsection 7.3.2, OpenFOAM has a strict criteria for organizing code in source files. This means that template files will also follow this criteria, by having definitions in "*.H" files, inline functions/methods in "*I.H" files and other declarations of functions/methods in "*.C" files.

Therefore:

• When using the NoRepository flag, this means that the included header will have the complete template ready for compilation. This is a must for when there is no instantiation already prepared somewhere else. i.e. in a repository.
• When not using the NoRepository flag, this means that the usage of the template is only a prototype for using other already instantiated classes or variables based on that template, which that are referred to in yet another header. I have not been able to find with quick searches for practical examples of this in OpenFOAM's code.

The two scenarios exemplified:

• Defined NoRepository:
  • We have a ex01.H+ex01.C template, that follows the coding standards used in OpenFOAM.
  • We have a main.C file that includes ex01.H. In it we have a variable or class created with that template.
  • The code is built as a single object file, since main.C sees all of the template's declarations and definitions.
• Undefined NoRepository:
  • We have a library exlib.so that uses ex01.H+ex01.C template. These two files follow the same coding standards used in OpenFOAM. NoRepository is defined here.
    • Library exlib.so has a class exlib that uses the template ex01.
    • The class exlib is defined is made in exlib.H.
    • The inner workings of class exlib are made in exlib.C.
  • The main application, with a single source file named exmain.C, will link to exlib.so. NoRepository is undefined.
    • It includes only the files ex01.H and exlib.H.
    • The contents of the files ex01.C and exlib.C are not visible to the main application.
    • Even if NoRepository was defined, ex01.C would be the only included/visible file.
  • In the end, the main binary uses the class in the library, without full knowledge of the template.

Best regards,
Bruno

[marupio]

Thank-you, Bruno. Very well explained!

[Hisham]

Hi Bruno,

So if I am developing a BC that has no template definitions, based on a BC that has template classes, it is safe to remove the #ifdef NoRepository part and yet still be able to use other template classes from other libraries (e.g. Field<vector>). Is that true?

Thanks
Hisham

[wyldckat]

Hi Hisham,

If your new BC is simply a class, and not a template class, then you don't need "NoRepository".

Best regards,
Bruno

[Hisham]

Thanks a lot!

[wyldckat]

Greetings to all!

I was searching for the possibility of somehow unroll templates and stumbled on this page: http://gcc.gnu.org/onlinedocs/gcc/Te...antiation.html

I was going to quote part of the page, but then kept reading and concluded that there is too much good stuff to be read about this "template repository" business!

Happy reading!
Bruno

PS: and no, I haven't found any preprocessor that unrolls templates... and have my doubts that such exists

[marupio]

I'm not sure if I'm addressing what you mean by "unrolling", but you should check out the feature/blockCoupledFVM branch in the OpenFOAM-extend repository:

http://openfoam-extend.git.sourcefor...lockCoupledFVM

We've implemented a preprocessor "for loop". The main files that do this are src/VectorN/include/VectorNRunMacro.H, and src/OpenFOAM/include/customUserDefines.H You'll see it is a fairly simple solution that keeps the "bloat" of preprocessor directives isolated to two files.

It solves a problem where we couldn't compile all possible instantiations of VectorN<int> because it became too large and crashed the compile. But we still wanted users to be able to choose which ones to compile for their purposes.

Maybe this isn't related to what you mean.

[wyldckat]

Hi David,

Thanks for the quick answer, but unfortunately no, I wasn't thinking of unrolling in the standard sense of for-loop unrolling.

I can't think of a better name for it, but my idea for unrolling templates was along the lines of:

1. I've got a template, e.g.:

   template <typename T> T min(T value1, T value2);

2. I'll need two sets of instantiations:

   double x = min <double>(y,z);
   int a = min <int>(b,c)

3. But since I've got a dumb compiler, I want to drop the templates and convert auto-magically the textual code itself from template "min" to actual "min_double" and "min_int", thus having a translated code without templates.

It felt that the term unrolling still made sense, when compared to the for-loop unrolling, where the content of the loop is duplicated and the loop count shortened in the same proportion...

But I guess this is one of those holy grail things...

Best regards,
Bruno

[marupio]

When we were trying to solve the VectorN problem, we looked into solutions that combine scripting languages with preprocessors. M4 was one idea... but I didn't want to add to OpenFOAM prerequisites, so I never really looked into its capabilities. Their site is old school.

[wyldckat]

Greetings to all!

Just to complement my (very) old post #3, I've found various examples in OpenFOAM of template repositories put into practice.

The OpenFOAM's thermodynamics libraries rely heavily on using multi-layered templated classes such as this example:

thermoType      hRhoThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>;

(Note: this was used in "constant/thermophysicalProperties" files in OpenFOAM versions 2.1 and older.)

Using OpenFOAM 2.2.x as reference, here's an example:

1. The resulting composite classes are not accessible directly, since we usually only have access to the base thermodynamic classes such as "psiThermo" and "rhoThermo".
2. But in order for them to actually be used, they have to be instantiated at some point at build time. This is where header files similar to "makeThermo.H" come into action: https://github.com/OpenFOAM/OpenFOAM...o/makeThermo.H
3. This header file "makeThermo.H" provides macros that assist in both the creation/instantiation of said classes from templates and then loading them onto object repository. The macros/functions used for loading onto the object repository are already described at openfoamwiki.net: http://openfoamwiki.net/index.php/Op...tion_mechanism
4. And where is this header file used? In the file "psiThermos.C": https://github.com/OpenFOAM/OpenFOAM...o/psiThermos.C
5. In "psiThermos.C" you'll see for example this:
   

   makeThermo
   (
       psiThermo,
       hePsiThermo,
       pureMixture,
       constTransport,
       sensibleEnthalpy,
       hConstThermo,
       perfectGas,
       specie
   );

   This is unrolled to two typedef'initions (assuming I didn't make any mistakes):
   

   typedef constTransport<species::thermo< hConstThermo<perfectGas<specie>>, sensibleEnthalpy >> \
       constTransportsensibleEnthalpyhConstThermoperfectGasspecie;
   
   
   typedef hePsiThermo<psiThermo, pureMixture<constTransportsensibleEnthalpyhConstThermoperfectGasspecie>> \
       hePsiThermopureMixtureconstTransportsensibleEnthalpyhConstThermoperfectGasspecie;

6. The last typedef'inition is sent to "addToRunTimeSelectionTable" a few times, depending on the pre-assigned associated classes. In this case, associated to "basicThermo" (hard-coded), "fluidThermo" (hard-coded) and "psiThermo" (derived from calling "makeThermo").
7. It is "addToRunTimeSelectionTable" that adds to the object repository.

Now, the problem is if we actually need direct access to one of these combo-classes. One possibility would be to use a selector function, but such is hard to find, at least according to this: http://openfoamwiki.net/index.php/Op...nism#Selectors

There are no macros available for this. You need to fully implement the selector functions yourself. For every constructor type, you need to declare a New in Base.H and implement it in Base.C. Follow examples of other selectors already written.

Nonetheless, you can always hack your way into this and create the necessary typedef by hand or through a copy-paste-modify methodology and overriding the meaning of "makeThermo". Then instantiate the very specific combo-class when needed.


I'll see if I can come up with an example of this in the next hour and I'll edit the post accordingly .
edit: see this thread: http://www.cfd-online.com/Forums/ope...tml#post424491 - specifically the post #11

Best regards,
Bruno