Projects/Cassius

While a very important girl was off visiting her grandparents, I resurrected work on Cassius! Thanks to a few nights and occasional Saturday afternoons, the interface is maturing to the point where I can almost use it, so I’ve decided to put it on GitHub.

Old code never goes away, it just goes back to the compiler.

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).

Despite being interrupted almost every five to fifteen minutes, I managed to get the backends for embedding Lua and Python sorted. Today I would like to start getting into making it useful for something besides evaluating scripts.

Cassius needs to allow two things in order to be useful to me: invoking the embedded languages procedures from C++, and a way to export code to the embedded language. My interest, is whether or not it’s actually possible to accomplish that using fairly standard C++.  I’m kind of hoping, to see just how far that can be pushed.

From experience, I’ve learned that you can expect something vaguely C89 compliant anywhere in the world but expecting C++ compilers to agree on all things template related, can be like asking a goldfish to walk on air – a bad idea! That’s why I rarely do more with templates than I have to. With how much compilers have changed in the last four years, I reckon it’s time.

Out of everything traditional C++ offers, most of it is just sub standard compared to newer languages. A lot of the code I’ve read over the years, I would hardly even count as C++ so much as C with classes, but people have developed reasons I guess. IMHO how C++ can interface with C code is a killer feature, that could be just as readily solved by adapting a C compiler to generate JNI glue code or some shit like that. Throwing on inheritance based OOP isn’t that killer in my books, when you look at languages like Ruby and Python. The real killer feature of C++ is what you can do with templates. While supporting simple generics are part of it, that could be done in C by (abusing) the pre processor and adjusting your Makefile. It’s the opportunities to get creative at compile time that make its it worth while, someday I really should see if any good books have been written on TMP in C++.

The way I look at it, macros make Common Lisp stand out from it’s younger peers, C++ templates make you drool, or curse compilers more frequently lol. Leveraging languages is why more than one programming language should exist.

One thing spending almost my entire life around computers has taught me, is that rarely is anything impossible, so much as it may just be a pain in the ass to get done. For R&R, my interest is in exploring whether or not a wrapper around scripting languages can really work without heavy introspection or SWIG style code generation.

Principally, embedding a scripting language amounts to initializing it, feeding it with code, and stitching together an interface between it and the desired parts of your C/C++ code. In my experience most time is spent on writing code to bridge C with the script language. It’s kind of like an adaptor for calling conventions, but in C rather than native code.

The question that interests me, is whether or not C++’s standard issue functors and binders, are good enough that it could be done without having to to cuddling up to much to a specific scripting engines embedding API, for each one being embedded. In most dynamic languages the manipulations needed are pretty trivial, but C++ is rather, more traditional. Because of that curiosity, I’ve had an idea on my mind for ages, which I dub “Cassius”. The idea is, to have an interface that knows how to embed several scripting languages, and use that to interface with the scripting languages, in a way more agnostic to which scripting language you’re using.

I thought of the name as a reference both to the Roman name and to Cassius Clay, better known as Muhammad Ali—because after adding support for a embedding a few scripting languages, it might very well knock me out ^_^. The part that I’m not sure, is whether or not, it is technically possible to do it in straight C++, or if the APIs would require more than is possible without using something like SWIG.

Sometimes for a change, it’s fun to ride an idea to the end of a tunnel without trying to speculate what’s waiting there.