There were quite a few comments on my last post. I’d like to clear up a few (imo) misconceptions there.

What I wrote in the last post is not enabled by the default in Qt. So, you should not have any problems during development while using auto with Qt5 (btw, it has almost the same behaviour in Qt4).

From my POV, it is not a bug, but rather an expected behaviour. I only tested the code after writing the blog post - already knowing and expecting the result I got. If you explicitly enable the optimization, it is expected that you know what you are doing.

The lazy evaluation here is a new feature that auto provides. And, as with any other new feature, you just need to learn how to use it.

That, combined by the desire to be as efficient as possible which makes QStringBuilder to use const references instead of copying the QString object, makes it behave like this.

This can not break the existing code for two reasons - you don’t use auto in it, and you probably do not define the QT_USE_FAST_OPERATOR_PLUS macro before including QString.

Question

What is the output of the following code:

QString separator = "/";
auto date = "14" + separator + "7" + separator + "2013";
separator = " ";
auto datetime = date + separator + "17:32";
qDebug() << datetime;

Expected output: "14/7/2013 17:32"
Actual output:   "14 7 2013 17:32"

What happened?

In his great talk, Volker mentioned the optimizations of QString concatenation via the auto, expression templates and QStringBuilder that allow to do a single memory allocation for all the concatenations in the example above.

I just wanted to repeat a warning I gave to the audience - for the people who were not present.

In this case, auto allows the lazy evaluation of the result (which provides the actual optimization). “Lazy” means that the separator value is only taken at the point of the actual evaluation which happens only when the QStringBuilder is being converted to a string in order to be able to output it via qDebug. At that point, the value of separator is ” “, and the old value”/” has been forgotten.

The lazy evaluation is usually a trait of pure functional languages (Haskell) where there is no mutable state. When you have the mutable state, you need to really pay attention whether you are using an expression template-based API.

When?

This mechanism is only used when either QT_USE_FAST_OPERATOR_PLUS or QT_USE_QSTRINGBUILDER are defined. And those are, by default, in KDE Frameworks 5.

A working mock for testing the underlying framework for Plasma shell switching:

{% youtube RoC4l3eTriE %}

RSI (Repetitive strain injury) is not an uncommon disorder in the geek world. It can range from a slight tiredness to a very unpleasant pain.

I don’t know how it should really be treated, but I know two things - it should not be ignored, and you should not, when you stop ignoring it, try to relax and rest your fingers by playing guitar after not playing it for more than a year. Air guitar should be fine if you don’t overdo it. :)

One of the first things I started doing as a precaution was to switch the mouse hand every once in a while, and to lessen the number of clicks by making a no-click application launcher.

The last step I took was a few days ago. Mainly because this summer is going to be very stressful for my hands, and my fingers don’t seem up to it at the moment. The last step was to remove the resistance of the keys on my keyboard. That is, to replace the keyboard with something else.

As you can see, I have replaced it with a virtual one (xvkbd) running on the exopc tablet under plasma active. It controls my main computer.

I expected it to be quite a productivity killer at first, but it turned out to be quite a pleasant exercise both for my hands (different motions, no resistance) and by mind (thinking of the shortest way to type a variable name by using the fuzzy completion of the vim’s YouCompleteMe plugin - haven’t typed more than three letters per variable in a whole day).

All in all, a rather fun setup. The only issue I’m having is that xvkbd is not meant for multi-touch so if somebody knows of a full-qwerty+special keys virtual keyboard that can be shown on one display and control a different one, I’d be much obliged.

The last post showed how to create a modern and safe d-ptr (pimpl) idiom. There were a few questions regarding the purpose of such a thing, when you can directly use std::unique_ptr or QScopedPointer. The main reason is that it provides additional safeguards from abuse by making the interface minimal. Most importantly, it does not provide an interface to get the raw pointer. (note: it does, but if you are able and want to write something like delete d.operator->() who am I to stop you)

Today, we’ll talk about something evil - singletons. Or, more precisely, the lesser evil brother of a singleton that lasts only while someone holds a pointer to it. Again, it is not something that is difficult to implement, even in old C++, but thanks to the new smart pointers of C++11 it starts to be more elegant.

template <typename Target>
class shared_singleton {
public:
    static std::shared_ptr<Target> instance()
    {
        auto ptr = s_instance.lock();

        if (!ptr) {
            ptr = std::make_shared<Target>();
            s_instance = ptr;
        }

        return ptr;
    }

private:
    static std::weak_ptr<Target> s_instance;
};

template <typename Target>
std::weak_ptr<Target> shared_singleton<Target>::s_instance;

There’s room for improvement (thread safety, interface), but it works quite well as it is.

And yes, I’m aware that it can be done with Qt’s pointer classes, or QShared* ones. :)