Programming

Currently Lua and Python are in the works, because Lua’s API is different from what I’m used to, and Python is well, not fun to embed but simple enough. Conceptually there is no major difference between a parameter list and a stack, it’s just a sequence of data at heart, and Python functions basically use sequence objects.

What would be awesome, is if the calls are defined in terms of stack manipulation, is to create a template method called Push, that users template specialisation in order to wrangle plain old data types and callables to the right scripting language types, so we would have something like this:

e->Run(SourceString("function f(a, b) print(a); return b * b end")
e->Push(/* instance of some type representing f() */);
e->Push("header message");
e->Push(2);
e->Call();

and rely on the compiler to Get It Right in figuring out the relevant overloads, e.g. Push. Somewhat probmatic is the issuance that Push needs to be part of the abstract base class but can only be defined by a concrete implementation of the interface; normally it would just be defined as a virtual method. That means it works like you would expect a class method to work by default o/. Only thing with that is templates cannot be virtual, so we would have to sidestep the whole vtable thing.

That’s a piece of cake thanks to C++ allowing the abuse of inheritance and casting:

/* An example */

#include <iostream>

template<class Impl> class Base {
  public:
    template <typename T> void Push(T arg)
    {
        static_cast<Impl *>(this)->Push(arg); 
    }
};

// implementation
class Impl : Base<Impl>
{
  public:
    template <typename T> void Push(T arg);

};

template <> void Impl::Push (int arg)
{
    std::cout << arg << std::endl;
}
template <> void Impl::Push (const char *arg)
{
    std::cout << arg << std::endl;
}

// subclass that just overrides one method
class X : Impl  {
  public:
    template <typename T> void Push(T arg);
};

template <> void X::Push (int arg)
{
    std::cout << arg * arg << std::endl;
}
template <> void X::Push (const char *arg)
{
        static_cast<Impl *>(this)->Push(arg); 
}

int main()
{
    {
        Impl test;
        test.Push(2);   // 2
        test.Push("string");
    }
    {
        X test;
        test.Push(2);   // 4
        test.Push("string");
    }
    return 0;
}

Because the parent class is templated against the derived class, it’s possible to get jiggy with it at compile time. Namely enough is known by the parent about the child to invoke the correct method. Where it becomes somewhat annoying is when you want to continue with subclasses, like X in the above example.

A year or two ago I learned that people call this the “Continually Reoccurring Template Pattern (CRTP)”. Being lazy, I just think of it as the poor mans way of doing something similar to what “virtual template <…> …” would logically imply, if only the effing compiler was that smart. For what I need, just mating instance method overloading with virtual method calls is good enough.

Now all that is trivial, the real gripe however is how do you properly make a “Convenience” method, let’s say one we can do like e->Call(/* variable number of parameters */); and have it do the appropriate magic for us based on the type.

Well, sadly we can’t so easily. To use a va_list, there has to be a way to access the type of the argument. Normally this is done the same way that printf() and scanf() work in C, taking a format string saying what type to cast each parameter to. Pythons embedding API actually does this to convert from C data types to Python objects. Someday I need to open up a C library and look at how va_arg() actually works, I’ve always assumed it’s some sort of hack around a block of memory and type casting. It’s trivial to implement that kind of thing, already have done it for testing purposes (rather than templated Push()’s) but using a format string to describe the specifiers breaks down on type safety, where as at least with the template thing, the compiler can help some.

We can’t rely on Push() overloads to do the right thing because va_arg() is needed to access the arguments if Call() takes a variable number of arguments in the C++ 2003 compliant way. Obviously the easist solution is to find a smarter way of doing va_arg(a_va_list, a_type). Life would be a piece of cake with templates that can take a variable number of parameters, right? Well there’s few  vendors out there who seem to know how to do that <_>.

So how the fuck do you do a smart va_arg() like behaviour? The only thing I can think of at the moment is to make them all the same templated type, so it’s known how to cast them; then try and work some sort of char_traits<> like magic to figure out which Push() is appropriate but binding the necessary info creates more of the same. That and looking up in the C++ standard how many template parameters (if any) compilers are required to allow, and generating every possible permutation of arguments using a script to make the necessary template code before calling the compiler.

Either way, I’m just taking a break for a few minutes to enjoy how peaceful the quiet has been for the last twenty minutes lol.

Been contemplating about a few things, that are arguably, the programmers equivalent to several mortal sins. One of these involves standardising my world around a given language setup. Yes, choosing the best tools for the job rather than the same tools can sometimes be troublesome.

The languages I’m considering, are C++ and C#. Python would be a good candidate except that I’ve waay to many lines of Python over the years lol. Behind the C++ factor, is simply put, Richard Gabriel was correct when he said “The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++”. Frankly programming in C++ is a bitch. It’s not so much the language, which has plenty of warts, as it is building projects causes headaches. Most of which is a mixture of complexity and the inability of people to manage that complexity before shipping it. The other factor, being C#. I’ve come to rather like C#, because it takes the best part of languages like Java, i.e. using bytecode rather than native code, but unlike Java 6, C# 3 and up is actually a modern fucking language. Java can kiss my rebel dick. It’s retarded.

C++ gives painless (as possible) support to C code, while adding some goodies: automatic ctor/dtor invocation, formal namespace schematics, semi-generic data structures, and often disabled or unused support for exceptions and runtime type information. There are also a lot of libraries written in C++, that are less than easy to use in other languages; the fact that many are often less than easy to use in C++, is aside from the point obviously ^_^.

C# is more convenient than C++, because of a more modern syntax (Java can really fuck a duck for all the modernness of it), and because it has the ultimate in language killers, which C++ lacks—A big fucking library. Where as C++ provides stream based I/O, container based data structures, and not much else beyond your systems C library. C# has a large cross-language class library, which essentially throws networking, XML, basic graphics on top of that, and a much more portable interface to system stuff, like Process class and the file system code.

That is the big killer: libraries that are easily incorporated. C++ lacks that. In fact, about the closest you can get is throwing in Boost, POCO, Qt, or Wx. Plus a few other odds and ends.

C# is a much more pleasant language to work in and takes the pain out of compiling projects, because it really can’t get much harder than which defines to set and which files to compile into what. Something that life would be fucking great if C++ could say the same, even on a single platform group. Unlike Java, it’s also possible to build C# projects promptly and trivially combine code with many other languages.

C++ however has a much wider range of libraries readily available without needing glue code, if one can stand the bitch and a half of making them work o/.