Daniel’s Blog

Bjarne Stroupstrup on C++0x

Daniel Elstner — Thu, 18 Mar 2010 12:09:54 +0000

I’m just back from Aalto University School of Science and Technology in Espoo, Finland, where I attended Bjarne Stroustrup’s roadshow talk on C++0x. In the talk, Stroustrup provided a very nice overview of the features in the C++ standard and how they fit into the evolution of the C++ programming language.

Bjarne Stroustrup made the impression of a down-to-earth guy with a very healthy attitude about C++ features and their development. I was excited to learn that the C++0x draft standard had just been declared final the week before. That means the content of the standard is de-facto finished now, and it will be formalized as an ISO standard in about one year. There sure are quite a number of nice goodies in C++0x, I can’t wait to get my hands dirty on code using it.

For the C++ groupies among us, I took photographs of all presentation slides and of course also of Bjarne Stroustrup himself.

Why I hate Qt

Daniel Elstner — Thu, 25 Feb 2010 17:21:27 +0000

Although I’m a GNOME and gtkmm guy, my paid work involves Qt. It’s no secret that I have a very strong antipathy towards the Qt mania to assimilate everything into their framework, the culture of their community, and their nonchalant abuse of the C++ programming language. Often, people suggest that I’m exaggerating the faults of Qt, and that there are much worse alternatives out there. Fair enough.

But today I happened onto another one of those little inanities which so often add up to a huge stinking pile. I decided to share this particular example, as I think it may help people to understand why I’m feeling so strongly about Qt.

A while ago, I filed Qt bug #5732, together with a patch to fix the problem. In addition to the fix for the central problem reported in the bug, I also provided a second patch to correct another problem I stumbled upon while I worked on the actual bug fix. The bug was acknowledged by a Qt developer and the code got fixed. They decided to fix it their own way instead of applying my patch, which is fair enough. I may not have agreed with the way it was implemented, but the problem I reported was fixed.

Today, I again looked at the Qt OpenGL code, and happened to stumble upon the OpenGL extension checks. Apparently, the extension checking had now finally been factored out into a separate class, with a more efficient implementation to avoid the numerous temporary memory allocations of the string splitting method that was used before. Of course I was curious and had a look at the code which implements the string parsing.

Here is how it looks like:

// This class can be used to match GL extensions without doing any mallocs. The

// class assumes that the GL extension string ends with a space character,

// which it should do on all conformant platforms. Create the object and pass

// in a pointer to the extension string, then call match() on each extension

// that should be matched. The match() function takes the extension name

// *without* the terminating space character as input.

class QGLExtensionMatcher

{

public:

QGLExtensionMatcher(const char *str)

: gl_extensions(str), gl_extensions_length(qstrlen(str))

{}

bool match(const char *str) {

int str_length = qstrlen(str);

const char *extensions = gl_extensions;

int extensions_length = gl_extensions_length;

while (1) {

// the total length that needs to be matched is the str_length +

// the space character that terminates the extension name

if (extensions_length < str_length + 1)

return false;

if (qstrncmp(extensions, str, str_length) == 0 && extensions[str_length] == ' ')

return true;

int split_pos = 0;

while (split_pos < extensions_length && extensions[split_pos] != ' ')

++split_pos;

++split_pos; // added for the terminating space character

extensions += split_pos;

extensions_length -= split_pos;

}

return false;

}

private:

const char *gl_extensions;

int gl_extensions_length;

};

According to the log message the piece of code just shown went through internal code review. For comparison, here is the equivalent piece of code from my original patch, which was not considered good enough to be applied:

static bool parse_extensions_string(const char* extensions, const char* name)

{

const size_t name_length = (name) ? strlen(name) : 0;

Q_ASSERT(name_length > 0);

if (extensions) {

const char* pos = extensions;

while (const char *const space = strchr(pos, ' ')) {

const size_t length = space - pos;

if (length == name_length && memcmp(pos, name, length) == 0)

return true;

pos = space + 1;

}

return (strcmp(pos, name) == 0);

}

return false;

}

So, instead of just taking the code handed to them on a silver platter, the Qt developers decided to roll their own version. Which I wouldn’t even consider a problem if it weren’t for the fact that the code that went in is longer, less readable, and generally ugly. It’s also broken, because there is not a single word in the OpenGL specification about glGetString() always returning a list terminated by a space character, contrary to what the code comment claims about “all conformant platforms”.

Simon Singh Wins Leave to Appeal!

Daniel Elstner — Wed, 14 Oct 2009 18:39:31 +0000

Rejoice! Simon Singh wins leave to appeal in BCA libel case!

And now it begins!

Using config.site to set default options

Daniel Elstner — Mon, 21 Sep 2009 17:20:22 +0000

Just a quick note about a little-used feature of GNU Autoconf: site defaults.

Until recently, I used to have a long list of assignments to module_autogenargs['...'] in my ~/.jhbuildrc file to set up default configure options for various modules. This became unwieldy and there was always one module I forgot.

Autoconf comes to the rescue with its support for site defaults. For illustration, here is my ${prefix}/etc/config.site file:

# Autoconf site defaults

test -n "$enable_silent_rules" || enable_silent_rules=yes

test -n "$enable_static" || enable_static=no

test -n "$enable_warnings" || enable_warnings=fatal

The effect is as if I had passed --enable-silent-rules --disable-static --enable-warnings=fatal to every module’s ./autogen.sh, except that I don’t get any annoying warnings if a module doesn’t actually support a particular option. The test conditionals ensure that command-line arguments have precedence over the default values in the config.site file.

Read the manual for the gory details, if you want to. Otherwise, enjoy!

C++ bindings now in GNOME Documentation Library

Daniel Elstner — Thu, 17 Sep 2009 10:17:34 +0000

After more than a month of infrastructure work, most of the GNOME C++ binding documentation has now been migrated to the GNOME Documentation Library. This includes the Programming with gtkmm guide and the Doxygen API reference documentation of the core C++ binding modules. Compared to the old documentation hosted on the gtkmm website, we’ve now got a bigger pipe, more bling, and less work for us!

All this would not have been possible without the help of Frédéric Péters, who did the actual integration work in the library-web module and has been very responsive to our numerous questions and tweak requests.

Leading up to the migration, the build infrastructure of the GNOME C++ bindings was completely restructured. All the copy’n'paste of build files had degenerated into an unmaintainable mess. When it became clear that we lacked the infrastructure to properly support cross-references from one documentation module to another, I began to cook up something new to replace the mess. The result of this work is the new mm-common module, which provides the shared build support files for the C++ binding modules. As a novelty, it even comes with documentation!

It is quite a bit of work to convert an existing module to use mm-common, and the transition took more time than I had expected. Despite that, the feedback was very positive, and a number of module maintainers started to convert their modules to mm-common on their own. Many thanks to David King, Fabien Parent, Jonathon Jongsma, José Alburquerque, Krzesimir Nowak and Murray Cumming for your work and feedback!