I started with Play with SYB and QuickCheck. In the end demonstrating and discussing Scrap your Boilerplate took so long that we adjourned Quickcheck.

Scrap Your Boilerplate in combination with the Language.C library gives you the power to implement source to source transformations of C programs with very few lines of codes. That's why I make heavy use of it in the implementation of the Ocram compiler.

Die Slides sind fast die selben wie beim letzten Vortrag. Allerdings wird es von diesem Vortrag bald eine Videoaufzeichnung geben.

Auf dem 28C3 hat es auch einen Vortrag über Bitcoin gegeben. Allerdings wurde dort, wie in vielen anderen Podcasts und Blogs auch, die Technik hinter Bitcoin nur oberflächlich erklärt. Viele Diskussionen über die Probleme und die Zukunft von Bitcoin setzen allerdings ein Verständnis der technischen Details voraus. Ich hoffe daher, dass meine Vorträge sachliche Diskussionen über Bitcoin fördern.

Here are the slides.

And tomorrow, Peponi will give a talk on Bitcoin at the Datenspuren which is a German privacy conference. In contrast to me, Peponi focuses on the financial aspects of Bitcoin.

Es ist seit dem Easterhegg ja einiges passiert mit Bitcoin. Dementsprechend ist das Interesse in der Hackergemeinde an dem Thema unbebrochen hoch. Ich bin echt gespannt, was noch passieren wird.

Hier sind die Slides.

Ich bin sehr zufrieden mit dem Vortrag, denn ich glaube, dass die wesentlichen Konzepte gut angekommen sind. Und es scheint ein wachsendes Interesse an funktionaler Programmierung i.A. zu geben. Sehr schön ;-)

Bitcoin ist eine denzentrale, digitale Währung. Der Schlüssel dazu ist die Idee, Konsens über globale Zustände im verteilten System zu begünstigen, indem ein Zustandswechel per kryptographischem Problem zeitaufwändig gemacht wird. Dadurch wird eine zeitliche Kollision unwahrscheinlich und das fälschen des globalen Zustandes nur möglich, wenn man mehr als 50% der Rechenleistung im verteilten System beherrscht.

Eigentlich war der Talk nicht geplant, aber nachdem ich zufällig mit Pesco über Bitcoin ins Gespräch kam und immer mehr um uns herum immer die selben Fragen dazu gestellt haben, dachten wir, dass man dieses Interesse mal mit einem Talk bedienen sollte. Zum Glück war noch ein Slot im Vortragsprogramm frei und die Orga flexibel genug, uns den spontan zu geben (thx mc.fly). Der Talk war dann auch gut besucht und es gab ziemlich schnell rege Diskussion. Immerhin geht es um Open Source, Kryptographie, verteilte Systeme, Geld, und Macht. Wer kann da schon ruhig bleiben? ;-)

Das Feedback war wie zu erwarten. Einige fanden es interessant und wollten mehr wissen. Andere meinten, dass das nie in der Praxis funktionieren wird. Man wird sehen. Zumindest im Bereich von drahtlosen Sensornetzwerken weiss ich, dass Model Checking verstärkt angewendet wird, weil klassisches Debuggen dort sehr teuer und zeitaufwändig ist. Ich denke, dass sowohl Theoretiker und alsauch Praktiker ihre Vorurteile mal auf die Seite schieben und gemeinsam daran arbeiten sollten, formale Methoden alltagstauglich zu machen.

Fortunatelly, there is the inotify API on Linux and associated inotify tools. They let you register callbacks in the user land when something happens on the file system. And even better, there is the PyInotify project, which provides Python bindings for inotify.

So, I went on and wrote react, which is a command line tool for inotify that is based on PyInotify. This tool monitors a directory recursively and triggers an external script every time a file that matches a user provided regular expression or shell file pattern is created or modified.

This tool really speeds up my vim-based software development. And it shows the value of bindings to a scripting language as I managed to finish the tool in under two hours. And as a side note: Python's argsparse is awesome! It is so good that I accepted to depend on Python 3.2. Hopefully this does not exclude too many users for now.

To make it short, what do you think does the following program print?

#include <iostream>

struct X { };

class Y {
public:
    Y (const X& x) {
        std::cout << "fnord" << std::endl;
    }
};

int main() {
    Y d(X());
    return 0;
}

At first sight it looks like everything is ok. We know that references to temporaries must be const, which is the case here. So we think, d is going to be a Y object which was initilized with a temporary X object. In this case, the program should output "fnord".

But it doesn't. Instead it prints nothing. Mysterious you think? So did I. So I started debugging the issue while Roker was giggling. So, if d is not a Y object, what is it then? Let's ask the compiler and the C++ runtime:

#include <typeinfo>
//...
int main() {
    Y d(X());
    std::cout << typeid(d).name() << std::endl;
    return 0;
}

The program now prints "F1YPF1XvEE". Hmm, I can not decrypt this, can you? We need to demangle the name in order to see it's real C++ nature:

$ c++filt -t F1YPF1XvEE
Y ()(X (*)())

Who can decrypt this? If you can't, here is a howto on reading C type declarations, because the unfamiliar syntax for function types is a C heritage. And what does this type mean after all? It means, that d is a function which returns a Y object and expects a pointer to a function which returns a X object and expects nothing. Got it? If not, here is how I would write it, in case I would need such a type:

#include <iostream>
#include <typeinfo>

struct X { };
class Y { /*...*/ }; 

typedef X (Inner)();
typedef Y (Outer)(Inner);

int main()
{
    Outer d;
    std::cout << typeid(d).name() << std::endl;
    return 0;
}

Ok, so now we know, what the program does. It declares a function. That's why there is no X object ever created. So, although the code could mean what we originally intended, the compiler chooses to understand something else, which is also possible due to the C syntax rules. Although I still don't know what function declarations inside other functions are good for, the compiler again prefers them. Anyway, what's the C way of removing ambiguity from syntax? Right, it's parantheses:

//...
int main()
{
    Y o((X()));
    std::cout << typeid(o).name() << std::endl;
    return 0;
}

To sum it up, this is yet another example for why I consider the C heritage to be a major source of trouble for C++ developers. The C syntax was never designed for temporary variables and combining both yields to what we have seen here: ambiguity, ugly workarounds and surprise and furstration for the developer. Don't get me wrong, though. I still think that C++ could hardly have been made better given the design goals which where taken those days. I truly have a love-hate for that language.

Today he pointed me at Cay Horstmann's list of C++ pitfalls. Some of the issues have already been covered here but some haven't. I recommend reading it to every C++ developer as this takes less time than learning it the hard way by debugging code. Have fun.

Concerning the iterator issues Cay provides a Safe STL implementation which is supposed to be used as a drop in replacement for the STL during development. It adds state and knowledge about the owner to iterators and uses this information to do runtime checks. If you accidently use your iterators in a wrong way you end up with a comprehensive runtime error instead of a segfault "deep in the bowels of STL code".

I haven't tested Safe STL. If anybody did feel free to send me your experience. I would be glad to blog about it.