All examples are built using the lightweight SleekXMPP Python XMPP library. In fact, SleekXMPP is so lightweight that we included a version in the source bundle, making it even easier to get started implementing your own bots and components.

Do bear in mind that these examples only serve illustrative purposes for the book, so don’t expect very robust code. Although making this code fail-safe is not really our primary goal (since that would involve a lot of code that would only distract the reader), we do welcome bug reports or fixes.

The code examples are available as a source package, or directly from the Git repository (mirrored on GitHub). We will soon put a link to the package on the book’s webpage.

To create our auto-updating application, we first lay down the auto-updater interface in a (pure) virtual class:

class AutoUpdater {
  public:
    virtual void checkForUpdates() = 0;
};

The Sparkle implementation of this interface has the following C++ header:

class SparkleAutoUpdater : public AutoUpdater {
  public:
    SparkleAutoUpdater(const QString& url);
    ~SparkleAutoUpdater();
    virtual void checkForUpdates();
  private:
    class Private;
    Private* d;
};

Note that I am using the Pimpl idiom to hide Cocoa-specific internals from the API into a private internal class.

The actual impementation of the SparkleUpdater needs to call Sparkle’s Objective-C API. However, we cannot write the implementation in Objective-C, since the header for our updater (which will be included from within our application) is written in C++. Luckily, GCC’s Objective-C++ extension allows you to mix Objective-C with C++ without any problem. So, we create an Objective-C++ implementation of our updater, and put it in a .mm file:

class SparkleAutoUpdater::Private {
  public:
    SUUpdater* updater;
};

SparkleAutoUpdater::SparkleAutoUpdater(const QString& aUrl) {
  d = new Private;
  d->updater = [[SUUpdater sharedUpdater] retain];
  NSURL* url = [NSURL URLWithString:
      [NSString stringWithUTF8String: aUrl.toUtf8().data()]];
  [d->updater setFeedURL: url];
}

SparkleAutoUpdater::~SparkleAutoUpdater() {
  [d->updater release];
  delete d;
}

void SparkleAutoUpdater::checkForUpdates() {
  [d->updater checkForUpdatesInBackground];
}

All we do here is create an SUUpdater (Sparkle’s updater class), set it up, and activate it in our checkForUpdates() method.

To integrate Objective-C++ classes into a Qt project, qmake provides the OBJECTIVE_SOURCES variable. Knowing this, we add our new classes to our qmake project file:

HEADERS += AutoUpdater.h
SOURCES += AutoUpdater.cpp
mac {
  HEADERS += SparkleAutoUpdater.h
  OBJECTIVE_SOURCES += SparkleAutoUpdater.mm
  LIBS += -framework Sparkle
}

Before we integrate the updater into our application, there is still one detail we have to take care of: if you write Objective-C code that creates objects, you need to instantiate an NSAutoReleasePool to enable Cocoa’s memory management. Although we could do this in SparkleAutoUpdater, we’re going to put this in a separate initializer class, so we can share this with other Objective-C++ implementations in our application. The body of this class looks as follows:

class CocoaInitializer::Private {
  public:
    NSAutoreleasePool* autoReleasePool;
};

CocoaInitializer::CocoaInitializer() {
  d = new CocoaInitializer::Private();
  NSApplicationLoad();
  d->autoReleasePool = [[NSAutoreleasePool alloc] init];
}

CocoaInitializer::~CocoaInitializer() {
  [d->autoReleasePool release];
  delete d;
}

Now all that’s left to do is integrate all this into our application:

int main(int argc, char* argv[]) {
  ...
  AutoUpdater* updater = 0;
#ifdef Q_WS_MAC
  CocoaInitializer cocoaInitiarizer;
  updater = new SparkleUpdater("http://el-tramo.be/myapp/appcast.xml");
#endif
  ...
  if (updater) {
    updater->checkForUpdates();
  }
  ...
}

That’s it! If you want to try this out yourself, just download the sources of this mini-project, build them, and off you go. Don’t forget to remove ~/Library/Preferences/be.el-tramo.mixing-cocoa-and-qt.plist to clear Sparkle’s state cache.

For example, this is what it says about the sus4 chord:

chordNotes Five = [(ScaleNote Major 1), (ScaleNote Major 5)]
chordNotes Sus4 = (chordNotes Five) ++ [(ScaleNote Major 4)]

So, sus4 is a power (5) chord (consisting of the first and the fifth of the major scale), added with the 4th note of the major scale. So, for Esus4, the program tells me:

Main> scale2notes $ Scale (read “E”) Major
[E,F#,G#,A,B,C#,D#]

Main> chord2notes $ Chord (read “E”) Sus4

[E,A,B]

Something else I forgot is:

intervals Ionian = [2,2,1,2,2,2,1]
intervals Major = Ionian
intervals scale = shift (intervals Ionian) (rank scale)
where rank …

So, every scale is really a shift of the major (well, any) scale, which is actually called the Ionian scale.

This program might come in handy as a summary of music theory in case I forget these things again

Spaces vs. Tabs: Use only spaces, and indent 2 spaces at a time.
We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.

I never really understood why so many people have such a hatred towards tabs. Is it just because they have seen code where some editor has mixed tabs with spaces (which of course results in a horrible mess)? Or do they have valid counter-arguments, even when tabs are used consistently?

Why would you force presentation of your code upon someone if you don’t need to? If you use tabs, you don’t need rules like ‘indent 2 spaces at a time’: I can choose whether I want 2 spaces, 4, or whatever indentation I feel most comfortable with when reading code. 

After some discussion, the pro-space people typically come up with the following piece of code, where they have their parameter names aligned:

void SomeClass::someMethodName(int parameterA,
                               unsigned int parameterB,
                               std::string parameterC)
{
    ...
}

No, you can’t do that with tabs, that’s true. But why would you do that in the first place (unless you’re using an editor which does such annoying auto-formating automatically)? When your method name gets too long, it won’t fit on your screen anyway. Why don’t you indent 2 tabs for your parameter names instead:

void SomeClassWithALongName::someMethodName(
        unsigned int parameterA,
        int parameterB,
        std::string parameterC)
{
    ...
}

Another popular argument is aligning member declarations:

FooClass foo_;
Bar      bar_;

Same remark: why would you do this? Does it really make your code more readable? Besides, it doesn’t scale: whenever someone comes along and has to add a VeryLongClassName member, your alignment  will be messed up, and you will have to change every member again.

My opinion: let the person who reads your code decide how he/she wants to see it, and lay out your code in a way it is flexible to be seen with different view settings. This avoids lengthy discussions about whether tabs should be 2, 3, 4, or 13 spaces wide. Besides, people have been preaching the separation of presentation and content for ages for HTML and CSS, why would this be any different for code?

Suppose you have a base class Oracle, and a derived class GeekyOracle, defined as follows:

  class Oracle {
    virtual int getLckyNmbr() {
      return 13;
    }
  };

  class GeekyOracle : public Oracle {
    virtual int getLckyNmbr() {
      return 42;
    }
  };

Being a good developer, you unit test GeekyOracle’s getLckyNmbr():

  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle* oracle = createGeekyOracle();
    assertEquals(42, oracle->getLckyNmbr());
  }

After a while, you realize that using abbreviations in method names is actually not very good practice, so you change your method name to something more readable:

  class Oracle {
    virtual int getLuckyNumber() {
      return 13;
    }
  };

However, when you compile your program now, it is behaving completely different than before, although all unit tests passed. It requires manual debugging to find out that you forgot to rename GeekyOracle’s method as well, causing Oracle’s getLuckyNumber() to be executed, no matter what oracle you instantiate. Your unit tests didn’t catch this, because they test every method of a class separately, but don’t test the class being used in your application.

A way to check for this in your unit tests is to make sure that, when testing a virtual method, you always call it on an object that is statically typed with its base class. In our example, our unit test would call getLckyNmbr() on an Oracle instead of on a GeekyOracle:

  void GeekyOracleTest::testGetLckyNmbr() {
    Oracle* oracle = createGeekyOracle();
    assertEquals(42, oracle->getLckyNmbr());
  }

This unit test will fail to compile when you change the method name of the base class, which avoids you end up with the silly bug in your program.

If your test allocates your object under test on the stack (e.g. for simplicity), you could use the following alternative:

  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle oracle;
    assertEquals(42, ((Oracle*) &oracle)->getLckyNmbr());
  }

However, since this degrades the readability of the test, I prefer to add a static helper method to my unit test, and write the test as follows:

  static inline Oracle* p(Oracle& foo) {
    return &foo;
  }

  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle oracle;
    assertEquals(42, p(oracle)->getLckyNmbr());
  }

Although I used C++ in my example, this technique should work for all statically typed languages. Advocates of dynamically typed languages claim they can compensate the lack of types by unit testing their classes properly; I wonder how they avoid this kind of problems, though.