After a discussion about open-sourcing a tool Szann recommended to make a puzzle about a topic that currently is irrelevant for software that relies on an open source tool chain.

C++ does provide a keyword "export". Most people don't even know about this keyword because unfortunately there currently is no open source compiler that does support it and commercial compilers that support it are quite rare as well. Instead of making use of the export keyword people are used to put all template code into header files that have to be included from every source file that creates concrete instances of the template code. This is a problem because it makes the compiler compiling the same code multiple times and it is a problem because commercial software vendors have to ship the full source code of template code of their libraries.

Explain how the export keyword can be used instead of including the full template code from each translation unit. Does this improve compilation time? Does this allow commercial software vendors to build a shared library of their template code instead of shipping the full code?

It is always important to have a good friend. C++ has a special keyword for this purpose. Thus you sometimes read code like this:

namespace n { template<typename T> void f(T o); }
class a { friend void n::f(a); };

Is this code correct? Do you have reasons for your opinion given you have an opinion at all? Ignoring the fact whether this code is correct or not, is it smart to write code like this or is something else to be preferred? Explain.

Because I had no time to do a puzzle today myself and there was still one from my former colleague Thomas in the queue I will present this puzzle today.

The question is what the following application does produce when built with a standard compliant compiler.

#include <iostream>

struct A {};

void foo(bool t) {
    if (t)
        throw A();
}

void bar(bool t) {
    try {
        try {
            foo(t);
            throw;
        } catch (const A&) {
            std::cout << "catched const A&" << std::endl;
            throw;
        }
    } catch (...) {
        std::cout << "catched ..." << std::endl;
    }
}

int main() {
    bar(true);
    bar(false);
    std::cout << "done." << std::endl;
}

If you want to test whether someone has understood how template specialization works is the following which is derived from a famous example by Peter Dimov and Dave Abrahams. So let's test you!

What's the return value of the function g in the following code? Explain your opinion!

template<typename T> int f(T) { return 1; }
template<> int f<>(int*) { return 2; }
template<typename T> int f(T*) { return 3; }
int g(int* i) { return f(i); }

Today's C++ puzzle was originally developed together with my student assistant Juergen as a geeky idea on how to write a full blown Java application without a main method. The same "technology" does work on C++ as well but you have to fake the linker with a symbol main to translate the program. You can do this by providing a global integer variable main instead of a main method.

Now for today's puzzle: Write a Hello World application without a function main. What is the drawback of this "technology" to write applications, apart from the obvious one that it is a ugly hack?

The following puzzle was suggested by my former colleague Thomas. Explain how to port a finally clause as used in Java to C++ without loosing its semantics.

Today I finally booked my travel to Brussels next month. In the afternoon I had a refreshing meeting of the faculty council. In the evening it started snowing a bit and thus I designed the following broken code:

namespace n {
    class c;
    void f(c&);
};

void f(n::c& v) {
    f(v);
}

Explain why this is broken code in C++.

The first public openSUSE IRC team meeting was held yesterday and went - in my opinion - very well. These meetings will happen bi-weekly now and are a direct result of the governance discussion on the opensuse list some months ago. You find the IRC log and meeting minutes here. Some of the topics were delegated back to the mailing lists for further discussions, please participate in these discussions on the topics you're interested in.

One of the ugliest things in C++ is reading complex type names. It is even uglier to deduce types from ugly code. It gets worst if templates are involved as well. We skip templates here for a first shot. Watch the correct(!) C++ statement 0[new weird](1)()(3,"strange")((weird(*)())0,5); and try to understand the syntactic meaning. Next describe the signature of the class weird that contains one method only.

I hope you will never _write_ code like that but you most likely will _read_ similar code if you have to work with code from other people. --- This is not a joke but a horror!

On Mondays people often write broken code. Actually they do it the other days as well but this leads to the following C++ puzzle for today.

The following code is broken and any instantiation of an object of a class derived from this abstract class is deemed to fail. Explain why this is the case. Note that your first thought might be wrong!

struct broken {
    virtual void v() = 0;
    void n() { v(); }
    broken() { n(); }
};