One value that this comment has served along with my compiler, is to teach me that default parameters on a template *function* are actually a C++0x feature, and apparently not part of C++03 as I have assumed for ages.
template <typename Num=int> Num square(Num n) { return n * n; }
int main() { return square(5); }
// g++ 4.5.1 reports:
//
// error: default template arguments may not be used in function
// templates without -std=c++0x or -std=gnu++0x
Somehow, I always figured if you could do it on template classes it would be legal on template functions as well. Guess that’s what I get for never reading the ISO C++ 2003 standard, and it having been a number of years since I last RTFM so to speak o/. About 95% of the times I use templates, it’s at the class level anyway, and most queries I have on C++ are easily solved by reading a header file. To be honest, while the drafts for C99 make for a very nice read, I’ve always worried that digging into the C++ standards might melt my brain or put me soundly to sleep. Frankly, C standards are helpful along side SUS, but the standards for C++, well all I can say is that I’ll be happy when 0x becomes as omnipresent as C89 capable C compilers. I’m just not sure I will live that long though :-(.
What I’ve done is implemented Engine::Call() as a sequence of template functions that use the vaguely normal method overloading semantics to cope with the arguments through Push(). Nothing else has been able to maintain the desired level of type safety. Basically if Call gets 0 arguments = use the current class state, and successive versions of Call(funcname, …) doing the obvious manipulations to generate the correct state and than run it. I would rather a recursive variadic template but life sucks and C++0x isn’t every where just yet. Having to supporting late model GCC 3.x is a real possibility for Cassius to bear fruit without thinning a few hedges.
Push() is just done as a set of virtual member functions for logistical reasons. Since each Engine instance is tagged with it’s language and implementation details (as an insurance policy), the same effect could be done through a set of template specializations and a little static_cast magic to forward it to the correct subclass without any inheritance tricks. At the price of a more stringent contract with subclasses, that would also allow for getting rid of other virtual members in the base class. I’m not what instructions a C++ compiler is likely to generate for a static_cast from parent to child class compared to what C++ virtual methods and casting things in C land will produce, but I could really care less about the cost of using virtual Push()’s versus templated Push()’s here: Call() is the one that matters at the template level. Why virtuals are used for Push() in point of fact, is to avoid a build time dependency against the backends (to be loaded at runtime), which obviously would be a circular dependency. So templated Call(), virtual Push() works more convineantly than a purely templated driven solution.
Being sublimely lazy, rather than write out a set of similar template functions for each version of Call() that’s needed to handle these successive amounts of arguments, I just wrote a Lua script to do it for me: then shoved that into the projects build scripts and adjusted the headers to include that auto generated file as needed. One of my favourite Boost libraries actually does something similar for handling a variable number arguments for a functor type class, but I’ll be damned if I’m writing them by hand!
Lately I’ve been relying on a mixture of rake (Ruby) and premake (Lua) based build systems, so it is rather nice to be able to do such things: and not kick myself later (make, vcbuild).