Reading the german Wikipedia entry about metaprogramming, I feared that my new "invention" (haha, what a coincidence...) of code generation (not execution) during compiletime is an old hat and already implemented somewhere with more effectivity than my own one (and thus a potential inspiration). Beeing extremely paranoid about breaking my head about stuff that's already great and as good as what I want, I noticed something really stupid. The meta programming can be interpreted as a) compile-time execution of code or b) compile-time code generation. Either way you can generalize it as compile-time execution, but it's essentially different in concept and use. I took a second look at Boost's Meta Programming Libray (MPL) and was kind of suspicious - what does it do? Is it really such an annoying set of extreme template nesting? Or is there something actually compiletime-based? So I downloaded it, studied the source code and was glad that it's really just a bunch of template classes with not real code relation but macros and so on. I almost fell into some kind of deep hole without knewing it. It wasjust an extremely short time feared my time was already wasted, but still... such multiply possible interpretations mix up my whole world, always all the time. Seriously, I UTTERLY HATE such stuff in programming or technical/scientific stuff in general. It's like saying your dad died but then adding that dying is a slang term for having bad sex or so... Whatever, it almost shocked me. Need to cope with that and don't just judge before looking at the actual library implementations. So I can keep on programming my really completely different approach!
Oh, and I think I found a possible solution to give some caller function a set of variables, define their input/output mode and then passing it correctly to a series of other functions depending on what you said in the template parameters. It's a bit smudgy in syntax, but should be relatively flexible. So it should be possible to implement new formulas and data flows based on template parameters and implicit isntanciation. Since all this stuff will NEVER work without inlining or basic optimization (like always replacing "(0>5)?(10):(3)" with "3" cause 0 will never be bigger than 5 and such), I can keep rely on the compilers smartness to such simple constructs. It's not possible without, so any simple rule based on constant expressions and inlining is valid here. Oh, and I also don't apply callbacks to such funcs or RTTI to their classes, so it's totally possible to get inlining "all the time" (there are still limitations, but these shouldn't be too restricting). It's good that I know how to cool me down and say myself that everything's right, that you don't need to worry about it. All this "maybe inlined, maybe not" is making me constantly nervous in moments of doubt and paranoia. That doesn't happen when everything's working fine, of course. Geez, the inner depths of programmers are quite dirty.