Jannis Pohlmann Personal website

Jannis

I am an open source enthusiast, student and musician from L├╝beck, Germany. In my free time I enjoy hacking on Xfce and Lunar Linux. I've been a member of both teams since about 2005. Besides developing software, I love to listen to and play music (Guitar, Bass and Drums) and hang out with friends.

Contact me via jannis@xfce.org. My public PGP key is 0x354AFBA6. You can download it from here.

My CV is also available for download.

Tag - programming

Entries feed - Comments feed

Wednesday, September 28 2011

On MeeGo

Whatever MeeGo was, it never made it into the open source mainstream, which I consider to consist of projects actively worked on by volunteers and companies alike, and didn’t manage to become an project attractive enough for individual open source enthusiasts not driven by money to make substantial contributions.

There is enough room to speculate over the reasons why this is. My personal take is that MeeGo failed to be a successful open source project because the corporate commitment to the open source idea was not strong enough and expectations were too high right from the start. 

Open source projects start with an idea and evolve into a proper product over time. Sometimes they are developed incrementally, sometimes it happens that big parts of them are replaced all at once. The idea behind an open source project may be huge but they all start off with baby steps. MeeGo, however, wasn’t supposed to. The idea behind MeeGo was big, and due to market pressure it was expected to become complete and successful quickly. It occurs to me that the idea was to sort of guarantee success by providing the project with professional, corporate governance. 

I think everyone who started working on open source as a hobby knows that this is something a lot of hackers are not comfortable with. An open source project under corporate leadership may easily suffer from top-down decisions that give developers the feeling of working in a restrictive environment rather than a playful one. I’m not surprised by the fact that the only people I know ever contributed to MeeGo worked either for/with Intel or Nokia.

It isn’t the technologies, tools or frameworks that are reason for the failure of MeeGo. KDE and GNOME are large and successful projects based on Qt, GTK+, Clutter, D-Bus-based desktop middleware etc. What has lead to failure in my eyes—the eyes of an outsider, open source developer and potential user—is that the dynamic nature of open source projects conflicted with corporate expectations and hopes for a quick success they needed so badly. Add to that the pressure on Nokia, the corporate culture clash of two global information technology companies and the fast pacing world of mobile devices and interfaces, and you have a pretty explosive mixture.

Personally, I won’t place my bets on Tizen. I can only imagine how frustrated and disappointed everyone who tried to get involved may be today, even those who contributed to MeeGo as part of their work for Intel, Nokia or one of the many smaller companies that make up the corporate part of the open source ecosystem. It is also frustrating for me as a developer aiming for a job in open source and desktop/mobile/UI technologies.

I guess the mobile open source platform we are all hoping for will be there some day. But it will only appear slowly, driven by the efforts of enthusiastic individuals with big ideas, realistic expectations and sound knowledge of the pace and dynamics with which open source projects grow and mature. This of course relies on open hardware and I don’t know enough about the manufacturing industry to predict the availability of open, hackable devices in the near future.

In the meantime, the best we can do as open source software developers is improve the base OS and innovate in desktop/mobile/UI technologies by experimenting with new ideas and extending existing frameworks. I’ll help where I can.

Thursday, January 6 2011

C++ exceptions can be dangerous

Just when you think you know everything about a programming language like C++, it will surprise you with new oddities.

I haven’t written any serious C++ code in a while but I used to be able to write it blindfolded. Yesterday, however, I came across a somewhat weird issue with exceptions that I am not sure makes a lot of sense.

Let’s assume you have a method foo and in there you have some code and inbetween you throw an exception, like this:

#include <iostream>
using namespace std;

void foo (void) {
  cout << "code before exception" << endl;
  throw 1;
  cout << "code after exception" << endl;
}

int main (int argc, char **argv) {
  try {
    foo ();
  } catch (int error) {
    cout << "exception caught" << endl;
  }

  return 0;
}

If you run this, you will of course only see the “code before exception” and “exception caught” messages.

Let’s add a local object to the scenario now, like this:

#include <iostream>
using namespace std;

class Object {
public:
  Object () {
    cout << "object constructed" << endl;
  }

  virtual ~Object () {
    cout << "object destroyed" << endl;
  }
};

void foo (void) {
  Object object;
  cout << "code before exception" << endl;
  throw 1;
  cout << "code after exception" << endl;
}

int main (int argc, char **argv) {
  try {
    foo ();
  } catch (int error) {
    cout << "exception caught" << endl;
  }

  return 0;
}

If you run the program this time, this is the output you will see:

object constructed
code before exception
object destroyed
exception caught

Notice how the object destructor is called properly as the object is local variable. It’s lifecycle ends when the program leaves foo().

Now, let’s change this again. We’ll throw an exception in the constructor and we’ll declare the local variable inbetween the code in foo():

#include <iostream>
using namespace std;

class Object {
public:
  Object () {
    cout << "object created" << endl;
    throw 1;
  };
  
  virtual ~Object () {
    cout << "object destroyed" << endl;
  }
};

void foo (void) {
  cout << "code before exception" << endl;
  Object object;
  cout << "code after exception" << endl;
}

int main (int argc, char **argv) {
  try {
    foo ();
  } catch (int error) {
    cout << "exception caught" << endl;
  }

  return 0;
}

Any guesses what output you will see now? Oddly enough, the local object will no longer be destroyed properly:

code before exception
object created
exception caught

So what does this mean?

  • Exceptions can make your applications leak memory. If large chunks of memory were allocated in the object constructor prior to the exception, they would not be released.
  • Exceptions in constructors are bad. If the code that can lead to the exception is moved into a normal method of Object instead of the constructor and if this method is called separately, the object will be destroyed properly.
  • Never be too sure about your knowledge of a certain programming language. There will be surprises. Always.