This is unintuitive and people have commented on it in several times.

With ZMQ_REQ_RELAXED enabled, calling send() while waiting for a reply becomes valid. It will give up on the old request and send a new one.

When enabling ZMQ_REQ_RELAXED, always enable ZMQ_REQ_CORRELATE as well. It ensures the receive call only reports the reply to the latest request. Otherwise, if the old reply comes in after all, you might receive that and think it’s the reply for the later request.

The new option only changes the behavior for send() in a state where it would previously have returned an EFSM error. It is safe to enable it in nearly all cases. libzmq wants to make it as easy as possible for users to migrate to new versions, however, so it is not enabled by default.

Contributing to libzmq has been simple and rewarding. They use a interesting “merge first, review later” process which sounds problematic – but which seems to work for them and definitely made me feel welcome as a contributor.

Keeping the noise out of a large fraction of iterator-based loops is great, but other common for loops are missing out! They have not received a convenient shorthand. Luckily, you can make some yourself by feeding the right containers to the range-based for statement.

For example, the regular counting loops

for (auto i = begin, e = end; i < e; ++i)
for (size_t i = 0, e = container.size(); i < e; ++i)


can be written as

for (const auto i : range(begin, end))
for (const auto i : indices(container))


if you define indices() and range() the right way.

Using the range-based version has no drawbacks: it is easier to read, quicker to write and compiles to equivalent assembly (calls to operator!= and operator++ get optimized away even at g++ -O1).

You can do a lot with the range-based for statement. What I have found useful so far is:

• range(begin, end): for (auto i = begin, e = end; i != e; ++i)
• range(end): same as range(0, end)
• indices(container): same as range(container.size())
• keys(container_of_pairs): shorthand for getting only value.first
• values(container_of_pairs): shorthand for getting only value.second

The code is available on github under the Boost Software License. It has no external dependencies and using it should be as simple as putting the header file into your include path. It is also fairly minimal, implementing only what is needed to make it work. A lot could be added, like rbegin(), rend(), generic reverse(), correct iterators, …

The approach has its limits, and one of them is exposed when you implement something like enumerate():

for (auto e : enumerate(c)) {
    // e.index is the current index
    // e.value is the current value
}


For standard containers (as well as the keys() and values() ranges above) the type in the for statement controls whether you get a copy or a reference of what you are iterating over as well as whether it should be const or not:

for (const auto e : c) // e is a const copy
for (auto & e : c) // e is a mutable reference


That can only work as long as what you want to put into e is an lvalue (i.e. c.begin() is an output iterator). It breaks down for enumerate() which cannot return a reference without extra overhead.

That is why I decided to split enumerate() into two functions. enumerate_byref() always grabs ‘value’ by reference and enumerate_byval() makes a copy. Usage then becomes:

for (const auto e : enumerate_byref(container))
    e.value = true; // ok, modifies container!
for (auto e : enumerate_byval(container))
    e.value = true; // ok, changes copy


Which is far from the ideal syntax, but at least it is explicit about what is going on.

Thanks to my employer, CeleraOne GmbH, for permitting me to publish this.

• RPATH and RUNPATH
• Qt Creator editor news
• New QML editor features
• Qt Simulator is going public

the first level of Star Guard

the same scene in the editor

A few things came together that caused me to make this level editor:

• I was looking for an excuse to do something interesting with QML.
• Star Guard is a great game and stores its levels in friendly, easily accessible XML files.
• When I emailed Loren about the project, he allowed me to use some of the game’s artwork.

The whole thing was surprisingly easy to do, took a couple of days and amounted to less than 1200 lines of code – one half of it QML and the other C++.

If you don’t know about QML: It’s a fairly new part of the Qt framework, essentially an extension of JavaScript to build user interfaces declaratively – and great fun to work with. All the details can be found on its documentation page and if you want to get started, the Qt 4.7 beta1 packages have just been released.

The editor uses QML to describe every aspect of the user interface. It’s turned out to be very useful in the beginning of the project when the editor was still QML-only and the interface layout and behavior changed a lot. It also means that it’d be very easy to redo the user interface now – even for someone without any C++ knowledge. Also, not having to recompile after every step simply makes fiddling with the UI a lot more pleasant.

Of course there’s the disadvantage of not following the native look and feel. But no one ever complains that most games don’t use it – and I don’t think it’s necessary for a level editor to look just like your spreadsheet application either.

The C++ part deals with the backend work, like providing a model that holds the map, a QML item that paints it, and loading from and saving to files. I used the QML plugin mechanism to expose these to the UI code.

The editor is fully functional; I consider it done and will not continue working on it. If someone wants to improve it or base his own tile based level editor on it, feel free! I release the code under the Boost Software License 1.0.

Linux binary (64 bit) and source code (12 MB)
Windows binary and source code (10 MB)
source code only (.tar.bz2, 20 kB)
source code only (.zip, 30 kB)

This is not a failing in itself. Indeed most users will never have the need or desire to compile their compiler from source. Yet it also prohibits testing patches for the front-end, makes debugging nigh impossible and generally complicates helping with DMD’s development.

The alternative – and often the only alternative if your target is not x86 Linux or Windows – is GDC. David Friedman took the open front-end and tied it to the GCC back-end, he even supports D 2.0 to some extend. While it works well and is fully open source, it has, unfortunately, remained a one-man effort. For me it was a combination of GCC’s daunting code base and the fact that there had been no activity for several months that stopped me from helping out.

Instead I eventually joined a different project: LDC. It is similar to GDC in that it also takes the open DMD front-end and aims to combine it with an equally free code generator. The back-end, though, is different: as the name suggests LDC emits LLVM bitcode, which can be compiled to native code, but could also be used for Just-in-Time compilation among other things. I’m also happy to say that even though LLVM is a large and ambitious project, it remains surprisingly easy to learn and work with.

Almost the first thing I did when I started contributing to LDC a few months back, was to integrate Thomas Kühne’s exhaustive DStress test suite with LDC: it is very useful for finding bugs and regressions and can even serve as a sort of crude progress indicator (crude because there is no relationship between number of bugs and number of tests; there are about 1000 tests for inline assembly and only 30 or so for exception handling). As you can see, there are still a handful (517 at the last count) of regressions with respect to DMD, but their number has been decreasing steadily.

In the last months, Tomas Lindquist Olsen, who started the project about a year ago and is responsible for almost all of its existing functionality, and I have added the last major missing parts to the compiler: inline assembly (thanks to David Friedman for the asm parsing and rewriting code!), exception handling and the synchronized statement are now supported. With these out of the way, goals for the future are squashing bugs, fixing some linking issues and getting LDC to work properly on Windows.

Speaking of other platforms: As Tomas and I both develop on x86 Linux, other configurations didn’t get much testing yet. Some people reported partial successes on FreeBSD and Sparc but more testers would be welcome. You can generally contact us by email or in #ldc on freenode. All in all, we’ve made great progress and if we can keep it up, LDC will be in the same league as DMD and GDC soon.

Long story short, I needed a way to read and write the MAT files that MATLAB generates and loads with the ‘load’ and ‘save’ commands. Using the C API directly seemed cumbersome and error prone, so this C++ wrapper was born.

Download it (4 kB) as .tar.bz2 or as zip.

A basic use case looks like this (also check out test.cc):

#include "matlabfile.h"
using namespace MatlabUtilities;
 
File matfile("some.mat");
std::vector<double> vec1;
matfile.read<Types::real_vector>("v1", vec1);
 
double[100] vec2;
matfile.read<Types::fixed_length_real_vector<100> >("v2", vec2);
 
matfile.write<Types::string>("hw", "Hello World!");


Not all MATLAB types are implemented (check Types namespace in matlabaccessors.h for a list), in particular real matrices with a column and row length different from one are missing for two reasons: I didn’t need them for the job and you probably have your own preferred matrix type anyway. But don’t worry, the template-design makes it easy to add these missing features. What needs to be implemented is

struct real_matrix {};
 
template <>
struct Reader<real_matrix, MyMatrix> {
    static void read(mxArray* var, MyMatrix& result);
}
 
template <>
struct Writer<real_matrix, MyMatrix> {
    static mxArray* write(MyMatrix& source);
}
 
template <>
struct TypeCheck<real_matrix> {
    static bool typeCheck(mxArray* var);
}


where the ‘read’ function reads data from the mxArray into result, ‘write’ returns a new mxArray filled with source’s data and ‘typeCheck’ returns true if the mxArray contains a real_matrix. With these template specializations in place you can use the new code like this:

MyMatrix mat;
matfile.read<real_matrix>("somevarname", mat);
matfile.write<real_matrix>("someother", mat);

Similarly, you can add a new reader to say ‘real_vector’ to accomodate for your own vector type.

The code snippet only contains code for reading and writing data. Other management functionality, like listing all fields in a MAT file is not implemented. I hope it will nevertheless be useful for someone.