QuoteOriginally posted by: MiloRambaldi(1) "Advanced" TMP, where the cartesian product of types is literally computed by meta-code. The example code for Method 1 is clearly the most elegant and concise. Currently this solution has the problem that computing cartesian products in TMP is very slow to compile even for moderately sized product, and even worse causes the compiler to blow up as the size grows. However, I believe that these compiler issues can be overcome by using the MPL package I mentioned below --- but this remains to be tested.So far, I like this idea the most. (Although, if possible, pruning would be useful -- I'd view it as a type-safety feature not to be able to use, say, CrankNicolson as, say, RandomNumberGenerator with a MonteCarloPricer ;]).BTW, before you spend time going too deeply into MPL, do you think you could take a look at Boost.Proto and see if it does what you need? Reason I'm bringing this up in this context: http://www.boost.org/doc/libs/release/d ... orQuote(2)
Run-time polymorphism. This is essentially BLOCK I in Cuchulainn's post below. It is easy to implement, but very inelegant, goes against the design goals and will cause performance degradation. (I'm assuming we agree that BLOCK II is not helpful for the problem at hand.)Please, no, if it's possible to avoid :-)Generally, run-time solutions have (by definition) weaker type-safety than compile-time solutions.Let's be honest here, both can result in non-trivial-to-debug programs.But I'd rather stare at N-deep stack of template invocations reported by the compiler from a buggy program that refused to compile, than have to go through a N-deep stack of virtual function calls in a buggy program that compiled and silently omitted reporting the problem until the very moment it occurred. Conjecture: compile-time polymorphism is easier to use, debug, maintain, and understand than run-time polymorphism.Quote(3) Hard-coding at the top level. I originally dismissed this solution, and it is unfeasible to write this code by hand in larger examples. However, perhaps the solution could be made feasible where the original source (which may or may not be entirely in C++) is compiled once to obtain intermediate source code which is then run through the C++ compiler. It seems inelegant to me, but perhaps this is a normal procedure for large projects... Yeah, this probably won't scale?