C++ Annotated: October 2018 – February 2019
Hi!
There are dozens of great events, thousands of interesting discussions, and a huge upcoming C++ release all happening right now in the C++ world. For this issue we have included a collection of interesting and engaging stories to our regular edition of C++ Annotated, we hope you enjoy them, please let us know!
Today:
- A look back at some of the recent C++ conferences: C++ in the Asia-Pacific region, new Embedded event, and the first edition of C++ on Sea.
- C++ Committee news.
- Proposals you can’t miss: Modules, Coroutines, and std::format.
- A few useful learning pieces.
- Recent releases.
C++ conferences
Many great conferences have been held since October. We would just like to mention a few here.
First of all, the Asia-Pacific region got a new conference in 2017, which grew bigger in 2018 – Pacific++. World-famous C++ speakers like Sean Parent, Titus Winters, Kate Gregory, James McNellis, and many others visited Sydney in October 2018 to meet the local C++ community. Check out the playlist with all the recordings from the conference, and definitely consider visiting this fantastic region for the 2019 Pacific++!
Meeting C++ 2018, in Berlin, was preceded by Meeting Embedded, a day which focused on embedded development and IoT. It was not a pure hardware event, but a day where developers could meet and discuss topics related to software development for the embedded & IoT sector. The day was opened by Dan Saks, and we really recommend you check out the interview he gave to Jens Weller, the founder and organizer of Meeting C++ and Meeting Embedded. Meeting Embedded was held for the first time but it seems it was a success (check out the trip reports from Rainer Grimm and the Conan team), and the speakers are known to the C++ community in general: Diego Rodriguez-Losada, Odin Holmes, and others. Video recordings of the talks from the Meeting C++ part can be found in the corresponding playlist on YouTube.
Imagine yourself on the beautiful UK coast, somewhere near Dover (full of white cliffs), looking across the channel at France, chatting with outstanding members of C++ community. Well, since it happened in February, you might need a bit of imagination to see the French coast on the other side, as it was quite foggy and drizzly:
That’s how the C++ conference by the sea was! Phil Nash ran it for the first time this year, but already managed to gather a great lineup of speakers! Just look: Kate Gregory was there with a thoughtful keynote on code written by human beings and some of the consequences of this, Nicolai Josuttis (whose talk on various ways of initializing in C++ is still one of our favourites!) with a talk on C++17, not with the traditional overview of the new features, but instead talking about the possible traps (a very practical approach indeed!), and a hymn to smart modern compilers in the keynote by Matt Godbolt (the creator of Compiler Explorer knows a lot about it!), plus many many others.
Let us ask Phil what his impression was of the first edition of C++ on Sea. Is he satisfied with how it all went – and what’s the plan for next year?
Phil: As an organizer it was my job to pay attention to every little detail and make sure everything went right (and try to fix it if it wasn’t) – so maybe I’m not the best person to ask? But the feedback I got in person, during and after the event, was overwhelmingly positive! I ran a feedback survey, in which I allowed submitters to remain anonymous. That too has been very positive. 90% of submitters rated the conference 4 or 5 out of 5 – with 65% rating it 5/5!
That’s not to say that nothing went wrong, that there was no critical feedback, or that there is anything that will need to be done differently next time. But I think most things that weren’t perfect are addressable. We’re looking to do it all again next year – the biggest question is whether to stay at the same venue. If we do, we’ll have to make some changes because it was very crowded in some places at times.
Aside from the logistical aspects, the content and social layers couldn’t have been better. We already knew we had first-rate, world-class, content – and our speakers really delivered. But we also had an emergent sub-theme of being a welcoming, inclusive, and just nice community – which was a benefit and credit to everyone and made me proud to be a part of it. Thank you all!
C++ Committee news
The 2018 Winter Meeting in San Diego along with the 2019 Spring Meeting in Kona have finally brought us to a feature freeze, leaving us with an amazing state for the upcoming C++20 release. Some people even call this future release the most powerful and important since C++11, which started the renaissance of C++!
Just take a look at the features lineup: Concepts, Contracts, Ranges, Coroutines, Modules (can you finally believe that?), spaceship operator, a whole bunch of new constexpr opportunities, and many others. Bryce Lelbach has written down the progress of both recent meetings in detail on Reddit:
- 2018 San Diego ISO C++ Committee Trip Report (Ranges v1 TS for C++20; consensus on modules design; new Language and Library Evolution Incubators)
- 2019-02 Kona ISO C++ Committee Trip Report (C++20 design is complete; Modules in C++20; Coroutines in C++20; Reflection TS v1 published; work begins on a C++ Ecosystem Technical Report)
A few words on Modules: The Tooling Study Group (SG15) has agreed to create a C++ Ecosystem Technical Report focused on modules’ interactions with the C++ ecosystem. This is a significant effort for smoother modules adoption across all the C++ tooling.
Proposals you can’t miss
In this section, we cover a selection of C++ proposals and initiatives you should definitely understand a bit about if you are developing in C++. We’ll focus on the parts affected by the recent C++ Committee Meeting in Kona.
Modules (C++20!)
P1103R2
This is one of the big three game-changing features we’ve been waiting for in C++ for a long time – and it’s finally here! In the recent committee meeting in Kona, the proposal that merged the Modules TS with the alternate proposal from Google employees was approved for merging into the working draft for C++20. That doesn’t mean that changes won’t be made before C++20 freezes, as Modules remain a hot area of debate.
But what are modules, or why is there such a big fuss?
To oversimplify: modules promise to be a replacement for what we call header files (and the whole #include model for exposing code for reuse). In the #include model, which happens during the preprocessing stage, header files are textually substituted into a single virtual implementation file that we call a translation unit. Because the headers themselves often have their own #includes, what we call the transitive closure of the entire set of files that make up a translation unit can very often be thousands – or even millions – of lines of code – even if you only wrote a few lines yourself. This has two main issues: (1.) the impact on compile times; C++’s notoriously bad build times owe a lot to this model, and (2.) poor visibility management; In order to use a symbol made known through a header file you often need to expose many more incidental symbols and layout details that will make your code more complex and less flexible.
A workaround for these issues has been somewhat common practice for many years. From the pimpl Idiom to Precompiled Headers to Unity Builds, these techniques are not always reliable, take a lot of effort to maintain, and introduce their own issues and overhead.
Modules promise to cut through all of this by providing a language mechanism to export only the symbols that should be made visible and hide all the other details. When a module is imported, it is this exported representation (in a partially compiled form) that is consumed. Object or Library files are still linked, as before, although working all this out should be taken care of by tooling.
In time, modules will change the way we write C++, and how it looks, to the degree that rivals that of the change to C++11.
Of course, the devil is in the details – and those details have been debated over at length for years. We’ve finally reached a state where the committee believes we have a system that works. But there remain unknowns when it comes to large scale adoption – especially in the area of tooling. So it is reassuring that the tooling group (SG15) are being given the responsibility of producing the C++ Ecosystem TR to aid tooling providers to work best in a brave new modules world. Those tooling providers, including JetBrains, are actively engaged, so support should already be in good shape when Modules finally arrive.
Coroutines (C++20!)
N4736 by Gor Nishanov
Another proposal that has been hotly debated for some years now has already been through a TS – and has finally been accepted into the working draft for C++20.
A coroutine is a function that may be suspended and resumed at specified points within the function. Of course, there also needs the means to call such functions, decide what to do while they are suspended, and a specification for what happens to the “bits in-between” – the glue that makes it all work.
The last part can be fully customized, but typically there are two main use cases: (1.) generators, which yield sequences of values lazily, and (2.) asynchronous workflows – a form of cooperative multitasking – ideal for event-based systems, such as networking.
With generators, values are yielded (more on that in a moment) one at a time, with the function suspended until the next value is requested.
With async, suspended code waits for some potentially long-running task (e.g., a network call) to return. In the meantime, the caller can be doing something else until it needs the return value. That doesn’t mean that async code is always multithreaded. In fact, it allows calls that would otherwise be blocking to be thread-agnostic.
All this magic is made available through three new keywords. To avoid clashes with existing keywords – and reduce the chance of clashes with other identifiers – they all have the co_ prefix.
You use co_await when calling a coroutine. In effect, you are saying that the code is “awaiting” a response from the coroutine. While it is waiting, control may be passed back to the caller to do other things.
A coroutine can return data without finishing using co_yield. This temporarily returns control back to the caller, along with some data, but it remembers where it left off, so it can be resumed.
To completely return from a coroutine you use co_return. It effectively works just like a normal return but includes the co_ prefix for consistency with the other two (in practice there are important differences about what happens between the co_return and actually returning – and what happens to the return value).
Using any of these co_ prefixed keywords in a function means that the function is, itself, a coroutine. As a result, we say that coroutines are viral – although there are ways to break out of this.
This brief summary omits many essential details – such as awaitable return types, the difference between stackful and stackless coroutines (C++20 Coroutines are stackless), and using Coroutines for other use cases that aren’t async or generators. But hopefully, it gives you an idea of how they will fundamentally change the shape of a lot of C++ code.
std::format (completing the specification)
P0645R5
The humble printf first appeared in C in the early 70s (and, itself, was based on BCPL’s writef from 1966). The first version of C++’s iostream library where added in 1984, and expanded in the first standard in 1998. iostream formatting was “better” because it was type-safe and memory-safe (in that it maintained its own buffer). Yet many have been disappointed with it in practice, and even fall back to the printf-family formatting.
So it’s great news that C++20 is adopting a third generation formatting library, which incorporates the strengths of both its predecessors, without all the downsides! A string formatter for a more civilized age, you might say.
std::format feels more like Python or C#’s string formatting approach – and, indeed, cites both as influences (as well as Rust). Braces are used as placeholders and may contain optional modifiers. Being type-safe, types can be inferred – so empty braces are common. But you can use some printf-style type specifiers, as well as other modifiers, for example, width and precision.
Arguments can also be positional, which means that localized strings with formatted insertion points may reorder inserted arguments as the language grammar requires.
If you’ve never been comfortable with the trade-offs between printf-style formatting and iostreams, std::format really does give you the best of both worlds. It may not be game-changing in the way that Modules and Coroutines will likely be, but it should make a lot of code nicer and easier to work with for very little investment.
Learning
Deprecation of Qbs
Qt Creator 4.9 will be the last release with support of Qbs. After that, the build system will be deprecated, and Qt will give preferences to qmake and CMake (the latter is growing significantly). In the future, it’s planned to switch to CMake for building Qt itself. So if you are still on Qbs, it’s now time to learn a new build system!
Debugging CMake
There was already an attempt to create a CMake debugger, but work there is no longer actively going in the branch. However, VisualGDB now provides the ability to step through CMakeLists.txt files, set breakpoints, and evaluate variables! This might look a bit crazy – whoever wants to debug the build system!? But with CMake, there is a real need for that. In this tutorial the process is explained step by step, from how to create a project in VisualGDB Linux Project Wizard, to launching the CMake Debugger, setting a breakpoint, stepping, and setting variable values on the fly. There is also the possibility to set a breakpoint on variable value changes so that a stop is triggered wherever a variable is changed.
Raging on ranges
Ranges are finally in the standard and will be shipped along with C++20! This is really a great move to increase the expressiveness of C++ code and (more importantly) solve some limitations of STL. In particular, it helps avoid passing begin/end to various collection iterators and makes the code more composable. Eric Niebler put lots of effort in making this happen, so kudos to him! And in December he wrote a blog post on some of the benefits and use cases for Ranges.
A huge discussion started in the C++ community (especially in the games industry), regarding the general readability of modern C++ code and some tradeoff here. A Twitter thread and blog post by Aras Pranckevičius raised a lot of questions in this direction. Ben Deane overviewed the current language state and ecosystem from the perspective of game development. Sean Parent finally participated in the discussion bringing his points and arguments in another blog post. So if you’d like to know what these long threads on C++ complexity were across the web in December, take a look at the linked resources – they more or less draw a picture of what it was all about.
A brief introduction to Concepts
As Concepts are finally coming with C++20, it’s good to know more about them than a basic definition (an ability to express constraints on template types). First, understand the Requirements, compile-time Boolean expressions, learn a few standard library concepts, and check out how it all works on a couple of non-basic examples.
Then go deeper, construct your own Concept, learn shorter syntax, and find out how overload works for concept function. All of the above can be found in two blog posts by Glennan Carnie: A brief introduction to Concepts – Part 1 and A brief introduction to Concepts – Part 2.
The Legacy Code Programmer’s Toolbox book
Jonathan Boccara is known for his Fluent{C++} blog and great talks (for example, “105 STL Algorithms in Less Than an Hour”). He has also published a book at Leanpub, and it’s dedicated to Legacy Code!
It promises not only to teach you how to read and understand legacy code, but also how to stay motivated when working with such code, diagnose bugs, and write documentation.
The real experience from a variety of software developers has been incorporated and instilled into the book making it a very precious artifact in the area. Check out the announcement for the book on the Fluent{C++} site and get the book from Leanpub!
Recent releases
CLion
CLion 2018.3 was released at the end of 2018. The biggest news was the Remote Development mode enabled in this version. It helps to develop remotely from a Windows, Linux, or macOS client machine to a Linux remote host. All run and build commands are executed on a remote host, while sources are synchronized automatically to the local machine so that the code can be resolved there.
Other improvements include Clangd-based navigation and search, CPU profilers on Linux and macOS, support for Git submodules, and various updates to Rust and Swift plugins.
The roadmap for 2019 was published soon after the release, and in January the Early Access Program for v2019.1 got started with ClangFormat, C++ naming conventions, and initial embedded development support.
ReSharper C++
ReSharper C++ v2018.3 tuned literally every smart feature the product has, making them work more precisely on modern C++ code. It all started with huge performance improvements, in particular, improved memory usage and optimized memory traffic, parallel cache loading on project reopening, and parallelized Find code issues command.
Besides this, ReSharper C++ can now detect formatting settings and has predefined naming conventions available in the settings. So that you can, for example, switch easily between Microsoft, LLVM, Google, or STL schemes. A more informative parameter view, new context actions, deeper knowledge of the dependent code, name hints, and better error diagnostics help you easily deal with modern C++ code.
As for the integration part, Catch 2.5 got supported, and Unreal Engine 4 support got some valuable enhancements.
Visual Studio
Visual Studio Preview 2019 started at the end of 2018 with C++ support in VS Live Share (where you can collaborate with your teammates by sharing the project, editing, and debugging in real time) and IntelliCode, which trains and puts the most used items on top of your completion list.
The second preview added support for the C++20 spaceship operator in the compiler, and brought a huge set of improvements for CMake projects. Other improvements include Lifetime checks update (the checks that detect dangling pointers and references, implementing Herb Sutter’s proposal in this area).
Qt Creator
Qt Creator 4.9 is now in Beta. It includes enhanced LSP support (and actually affects all languages, not only C++ in particular) by adding document outline, find usages, and some refactoring and quick-fix actions to the available API.
Profiling using Perf is now available for applications running on local Linux or a remote Linux system on a Linux or Windows host.
Subscribe to CLion Blog updates
