Qt World Summit 2019
The summit report
Qt World Summit is definitely the biggest event of the Year for the whole Qt community. It has been organized by The Qt Company itself since 2015 and traditionally takes place in Berlin. The event consists of three days full of talks, lectures, and workshops unsurprisingly mostly related to the Qt Framework.
The Qt Framework is our bread and butter in the development team of the Memsource Editor for Desktop, which is now Phrase’s CAT desktop editor (hereinafter “editor”), as the editor has been built on top of it. It is a professional, multi-platform, general-purpose C++ framework that serves our needs well and we’re always looking forward to its new versions and features.
We decided to visit the summit for the first time to be updated with the latest news in the field and to learn how to leverage the power of the Qt Framework even better.
In this blog post, I’m going to give a brief overview of the summit and highlight the parts we found particularly interesting. It’s going to be somewhat technical but I’m not going to go too deep into the details.
Day 1
The first day of the summit was the day of workshops. There were eight of them running in parallel, each lasted the whole day. We attended two workshops.
Modern C++ — What’s New in C++17? by Marc Mutz
We currently use the C++14 standard in the editor and the version of the Qt Framework we use (Qt5) is based on C++98. But C++ is evolving rapidly and the Qt Framework with it — the next generation (Qt6) is going to be C++17 based and all the clients of the framework will have to adopt the new standard as well.
As it is not that easy to keep track of all the new features of the language, this workshop provided a solid theoretical and practical overview of the C++17 standard. We can, for example, point out one less known but very nice feature: structured bindings. This feature enables something called de-structuring initialization which may especially be familiar to Python developers. The following code snippet exposes one use case which will probably become a typical one:
std::unordered_map<std::string, int> mapping
{
{"a", 1},
{"b", 2},
{"c", 3},
};
// C++14 version
for (const auto& mapping_pair : mapping)
{
std::cout << mapping_pair.first << mapping_pair.second << '\n';
}// C++17 version featuring de-structuring initialization
for (const auto& [key, value] : mapping)
{
std::cout << key << value << '\n';
}
This mechanism is general and works for all structure-based entities. It has the potential to simplify significant parts of our code and make it much more readable.
Profiling & Debugging Qt Applications on Linux by Milian Wolff
If you write your code in C++ you typically want it to be fast and performant otherwise you would probably not bother using C++ in the first place. But writing the code in C++ is not enough and you often find yourself surprised that your code is by far not as fast as you would expect it to be. Maybe the design decisions you made along the way were not right, maybe the algorithms you selected were not exactly great for the job… you know the drill.
When you have no idea where the bottlenecks may be and how to identify them, you should stick to the golden rule: measure first. And no, you do not need to flood your code with timers and logs, there are tools to help you — profilers.
This workshop presented perf (Performance Analysis Tool for Linux) and an additional tool called Hotspot which is able to nicely visualize perf’s reports via user-friendly GUI.
We also learned that VTune Amplifier, a great performance profiler from Intel, now has a free commercial license which can be refreshed an unlimited number of times. Unlike perf, VTune Amplifier also works on Windows.
As for the debugging, we were enlightened with rr. A debugger which aims to replace gdb in your workflow. The double r stands for Record and Replay. And that is exactly how it works. First, you record the program execution and then you replay it in the debugger.
The advantage of such an approach is that even though your program’s behavior might be non-deterministic, its replay is always deterministic. That can, for example, be extremely useful for clunky tests. You just need to record their execution on the CI and then replay the record whenever the test fails.
The other killer-feature of rr is its ability to perform fast and reliable reverse execution with commands like reverse-step, reverse-next, etc. Those commands enable you to go back in program execution which, when used for the first time, feels almost like magic and is really really helpful as you can probably imagine.
Apart from that, the CLI and overall debugging experience of rr is basically identical to gdb’s so if you are used to using gdb you can start using rr right away.
Day 2
The second day of the summit was the first day of talks. There were plenty of them, often running concurrently, which sometimes made it hard to choose as the topics were exciting. Here is an overview of two of them.
Verdigris: Using Qt Without moc by Olivier Goffart
The Qt Framework relies heavily on the Meta-Object Compiler (moc): a code generator which adds meta-object information to selected classes. The added information is later used to more or less mimic reflection, which is not present in C++ itself, and also for other things important for handling Qt’s signals and slots mechanism.
Many people don’t like the idea of having the non-standard 3rd party code generator and the generated code an integral part of their project. Also the moc tends to slow down the build for large projects and the fact that the moc does not support parallel processing makes it even worse.
An interesting project created and presented by Olivier Goffart is able to replace the moc with a set of macros and templated constexpr code producing binary compatible results with the moc.
We are currently not thinking of replacing the moc since its downsides are not that pressing for us, but it is good to know that there is at least an alternative to chose if needed in the future. Also, there is currently no tool capable of helping with the transition so it would be a lot of manual work and/or scripting.
Building a Qt Application with Modern CMake and vcpkg by Alexandru Croitor
The Qt Framework comes with its own build system generator qmake and encourages its clients to use it. It is simple, very well readable, and pretty neat for most common cases. But it is much less versatile and powerful in comparison with the build system generator which has become an industry standard over time — cmake. That is the reason why cmake will become the default and preferred build system generator from Qt6.
This talk presented the way of moving from qmake to cmake on fairly simple projects (our build is quite complex) but gave us some tips and tricks on how to overcome the obstacles we had been facing when previously trying to introduce the cmake build into our project. As a result, we have succeeded in creating an experimental cmake build running on our CI. It is still limited in supporting all the features of our qmake build but we are extending it further and are quite positive that it will become our primary way of building in 2020.
A brief list of benefits the cmake build can bring us is as follows: native support from all sorts of IDEs, easy integration of Conan package manager for 3rd party dependencies, building the application and the unit tests from one configuration, etc. Plus there are plenty of cmake modules out there helping with things like clang-format, sanitizers, code coverage…
Day 3
The last day of the summit had the same structure as the second day. I’ll describe two talks in more detail again.
Improving Your Code Using Clang Tooling by Kevin Funk
In C++, we have no garbage collector and the memory management is completely in our hands. That has many benefits but it also comes at a cost. That cost is (apart from increased complexity) a potential for memory leaks. New C++ standards are helping with smart pointers, the Qt Framework has a system of object hierarchy. But none of these is a definite cure, as they address only a specific subset of use cases, and in a large code base, memory leaks will always be something you need to take care of as they can become a serious issue.
Since valgrind is basically a standard tool on Linux used for detecting memory leaks and our CI is Linux based, we were always considering its integration into our pipeline. But there is one major pitfall: valgrind is slow. Really slow. Your application will run approximately 40 times slower under it. That makes it hard or even impossible to use on large projects and it makes complex GUI applications (like we have) painfully slow and unresponsive. You would probably end up testing only some subsets of your application or for example the unit tests with valgrind, not the whole thing.
But this talk indicated that there is a game changer now. They are called sanitizers and they are special pieces of code injected into your code by the compilers to check for all sorts of issues in your code at runtime. They can check for memory leaks, undefined behavior, and even data races.
The great thing about sanitizers is that they are fast. Application with all sanitizers enabled runs approximately 4 times slower compared with valgrind. Also, it is pretty straightforward to enable them as it is only a matter of proper compiler flags.
Clang and GCC are leading at sanitizers since they have been supporting them for a few years already. They both offer more or less comparable functionality and their implementation is mature and well settled. MSVC, on the other hand, offers only one sanitizer (AddressSanitizer) which was introduced this year into an upgraded version of Visual Studio 2019.
We are currently thinking of running all the tests on our CI with sanitizers enabled. It is very promising and tempting but let’s see how the practice will be.
Introducing a New OS for Qt: Lindows… or is it Winux? by Romain Pokrzywka
This talk, with a rather confusing title, basically presented guidelines on how to write bash scripts that run on both Linux and Windows. The platform used to run the scripts on Windows was WSL (Window Subsystem for Linux).
The speaker showed us that by using these guidelines, they had been able to write universal scripts running under both OSes capable of building their complex environment which had also included the Qt Framework.
Our Editor also targets both Linux and Windows and we currently maintain separate sets of scripts for building the environment we need for being able to test and debug. We would love to have just one set of scripts and we have already planned to do so using the mentioned guidelines.
Conclusion
The Qt World Summit 2019 in Berlin was great and we very much enjoyed it. We gained a lot of new ideas and inspiration which we hope is obvious from this blog post. We also understood where the Qt Framework is heading and how big and active its community is. Last but not least, it is always nice to meet people in person and have the opportunity to discuss ideas.
From an organizational point of view, we had no objections. Everything worked like clockwork. We can only say: “Thank you and see you next year!”
