Category Archives: design quirks

Template Metaranting

Posted by Kajtek on

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: 

 1:  struct Foo {
 2:    template<int N>
 3:    void bar() {}
 4:  
 5:    template<int N>
 6:    struct Bar {};
 7:  };
 8:  
 9:  template<typename T>
10:  void f() {
11:    T foo;
12:    foo.template bar<0>();
13:    typename T::template Bar<0> b;
14:  }
15:  
16:  int main() {
17:    f<Foo>();
18:  }
19:

Continue reading →

Romans, rubies and the D

Posted by Kajtek on

There’s an increasing interest with the D programming language amongst my readers so I figured I’ll post a bunch of short posts about D and see what happens.

Anyway, here’s a classic example showing Ruby’s capabilities taken from Seven Languages in Seven Weeks: 

class Roman
  def self.method_missing name, *args
    roman = name.to_s
    roman.gsub!("IV", "IIII")
    roman.gsub!("IX", "VIIII")
    roman.gsub!("XL", "XXXX")
    roman.gsub!("XC", "LXXXX")

    (roman.count("I") +
     roman.count("V") * 5 +
     roman.count("X") * 10 +
     roman.count("L") * 50 +
     roman.count("C") * 100)
  end
end

puts Roman.X
puts Roman.XC
puts Roman.XII

Continue reading →

Properties in the D programming language

Posted by Kajtek on

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.
Continue reading →

Mixins make sense

Posted by Kajtek on

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?
Continue reading →