|
[Sponsors] |
September 4, 2020, 10:24 |
RunTime Selection and the Templates mess
|
#1 |
Member
Elwardi Fadeli
Join Date: Dec 2016
Location: Boumerdes, Algeria
Posts: 41
Rep Power: 10 |
Hi,
The current implementation of the macros building up the RunTime selection components works well with classes and class templates which have only one template argument. But, you can't (easily) use them if you have, say, a base template with 2 template arguments and an identical child class template because these macros define a variable whose name contains the Targ passed to the macros. Hence, you can't pass (int,float) to the macro because we can't have commas in variables' names. Note that I'm fully aware that Maco Meta programming is possible (P99 for example) and that it can be used to "Concatinate" variadic macro arguments. But adding such dependencies just for this single feature is not feasible. So, I went ahead and prototyped new versions of the most common macros (At least the ones I use frequently) using variadic macros. The only difference from the standard macros is that you now have to provide a name for the template argument list (just like you provide a name for the constructor's parameter list). The code is tested on two-arguments templates for now and it works well with a single-argument template. This line defines RTS Table for the base class with Template arguments int and float. This line then adds a child class with the same Template arguments to the RTS Table. Note that "IntFloat" is the name of template argument list and can be anything. You can check the implementation of the macros yourself. My questions are: 1. Is there a particular reason this wasn't the default approach? Maybe OpenFOAM code didn't need such feature? 2. Over the years, the turbulence models for example have gained many levels of inheritance but the runtime selection was always involved in single-argument template. I feel like the code was designed to achieve this! Is there anything I'm missing here. 3. Doing it my way, I just the most generic class template and then start specializing member methods (or the template class as a whole for that matter) as I see fit. Is there any flaw in this design? Best regards, Elwardi |
|
Tags |
runtimeselection |
Thread Tools | Search this Thread |
Display Modes | |
|
|