Here's another post in the series, this time it's C++ vs. the D programming language.

Let's talk about templates. If you've ever tried templates in C++ you surely as hell recall the pages and PAGES of compiler errors and seemingly random placement of typename keyword. Trust me, there are EVEN WORSE problems with templates in C++... Consider the following:

struct Foo {
  template<int N>
  void bar() {}

  template<int N>
  struct Bar {};
};

template<typename T>
void f() {
  T foo;
  foo.template bar<0>();         // Line 12
  typename T::template Bar<0> b; // Line 13
}

int main() {
  f<Foo>();
}

Here's a little something I was actively developing arround this time last year and recently ported to Linux. It's a little game me and a couple of guys made while in SKN Shader.

Here's a video, make sure to watch it in HD!

I had very little time for this blog lately, but this is about to end soon enough. Here's a quick post showing ASM' keyboard distribution.

This post shows the Particle System and its editor me and Raver wrote for the LRRH project.

Here's some demo-steam: I have since deleted my YouTube channel.

Just to evangelize D a little and increase my code/crap ratio, let's pretend we develop a library in C++ that contains this class:

class SomeMetaVariables {
    public:
    std::string foo;
    bool bar;
};

// ... Somewhere in the client code:
SomeMetaVariables baz;
baz.foo = "foo";
baz.bar = true;

Our library is quite successful and many people are using SomeMetaVariables despite its obvious flaws. Now, say we get many requests for additional functionality, for example: "Make bar true only when foo is set to "foo" and other way arround." "Well, ok." - we say and commit this new version of SomeMetaVariables:

class SomeMetaVariables {
    std::string foo;
    bool bar;

    public:
    std::string getFoo() {
        return foo;
    }

    std::string setFoo(std::string newFoo) {
        foo = newFoo;
        bar = (foo == "foo");
        return foo;
    }

    bool getBar() {
        return bar;
    }

    bool setBar(bool newBar) {
        bar = newBar;
        foo = bar ? "foo" : "";
        return bar;
    }
};

We implemented the requested feature, but SomeMetaVariables' interface has changed... "But why are you mad clients? You asked for it!" - cries the C++ developer.

I've been called Kajtek "MOTHERFU*KINGWALLOFTEXT" Rzepecki lately, so let's make this post short.

We've got this code:

#include <iostream>

class A {
    private:
    int bar;
    void foo() {
        std::cout << "In A::foo() " << bar << "\n";
    }

    public:
    //...
};

int main() {
    A* a = new A();

    //...

    delete a;
    return 0;
}

And we feel a sudden urge to call foo() or access bar. How do we do that?

Let's suppose we have this class hierarchy:

It's a fairly specialized class hierarchy providing some functionality, let's say for the sake of this example that SomeClass provides a kind of player-game interaction interface and HierarchyWith defines it as a trigger based interaction (as in "a player does something - it triggers a response"). Our ExampleClass represents an entity that can be triggered by the player and that generates some response and in addition to that is further specialised to have some concrete functionality - let's say it's a lever that a player determined enough can pull to flood something with delicious magma. As we clearly can see ExampleClass is well-defined in terms of OOP, it's highly specialised and modular, but as an in-game entity it lacks a rather crucial functionality - it can't even be displayed on the screen. What do we do now?

Testing in programming is pretty important, no doubts about it, too bad that some languages make it difficult to test the code easly. For instance C++ is pretty limited in terms of DbC and unit testing. All it ever supplied to programmers was a little =assert()= macro that stopped the program providing minimal info about the error and the place it was "caught" in. I mean there are exceptions in C++ and they are pretty usefull, but still it's not enough and requires lots of effort in lerning and implementing correctly. One can still say there are libraries such as CppUnit for those purposes, but we all know how it goes - the more I need to do to get some minor advantage the less I'm interrested in it, and unit testing is so underestimated it's not considered an advantage to have a working piece of code anymore, how about that? And speaking of DbC in C++... It is possible... bam (A sound of a thousand readers going "whaaa" this instant.)