C++ on Sea 2023: Trip Report

Last week, from 27th to 30th June, I had the privilege of attending and presenting at C++ on Sea 2023 [C++OnSea] for the 4th time in a row! Despite having been accepted as a speaker, I was not sure if I would make it this year, as I changed jobs recently, but my management at Spotify was encouraging and supportive. They granted me the time so that I didn’t have to use my vacation days. Also, I am grateful to my family, in particular to my wife, for taking care of the kids alone for the week.

Let me share with you a few thoughts about the conference.

First, I’m going to write about the three talks that I liked the most during the 3 days, then I’m going to share 3 interesting ideas I heard about and then I’ll share some personal impressions about the conference.

My favourite talks

Over those few days, I pondered a lot about what makes a talk good and enjoyable. What makes a presenter good, at least for me? While my thoughts are not crystal clear yet, I definitely enjoyed talks that covered ‘beginner’ topics in depth. Another feeling I have is that good presenters limit the amount of knowledge they want to share so they have enough time to explain and they don’t talk at the speed of Eminem.

Special member functions in C++ by Kris van Rens

Kris’s talk [vanRens23] about special member functions in C++ is a good reminder of how difficult it can be to write a simple class in C++. Especially if you cannot follow the rule of 0. But do you know about the rule of 0? Or the rule of 5? Or the rule of four and a half? ☺

At first, I was not sure if I want to mention this talk among my favourite ones. But as I listed 2–3 favourite ideas from this talk, I realized that this in fact was one of my best picks.

Let’s see those ideas.

Have you heard about the Hinnant table [Hinnant20]? The one in Figure 1 shows when you can or cannot rely on the compiler to generate the special functions for you.

Figure 1

Kris shared how you can memorize it easily. While the table has 42–48 fields (depending on whether you count the diagonal), you only need three rules in order to memorize it.

• When the user declares any other constructor then the default constructor is not declared
• When the user declares any copy or move operation or the destructor, then the move operations are not declared.
• When the user declares any move operation then the copy operations are deleted

Another idea I really appreciated was that we should test special functions. You might think that testing those are cumbersome. But not so! You don’t necessarily want to test the internals of a copy constructor. You don’t necessarily have to test if all the members are copied promptly. Maybe you want to, but you don’t have to go that far.

It’s already a great step if you can ensure, with the help of type traits (or concepts) and static_cast, that a given class satisfies certain characteristics (see Listing 1).

class X{};
static_assert
  (std::is_trivially_destructible<X>{});
static_assert
  (std::is_trivially_default_constructible<X>{});
static_assert
  (std::is_trivially_copy_constructible<X>{});
static_assert
  (std::is_trivially_copy_assignable<X>{});
static_assert
  (std::is_trivially_move_constructible<X>{});
static_assert
  (std::is_trivially_move_assignable<X>{});
			

Then even if you modify the class, you make sure that you don’t lose its copyablity. Such tests might even enhance your understanding of how certain types of members influence a class.

While I think these tests also serve documentational reasons and they would look great in the header file along with the class declaration, probably it’s wiser to put them along with the unit tests so that you don’t make the compilation of the production code any longer.

One last thought! An explicit =delete is better than relying on that others know the Hinnant table as well as you.

Typical C++, but why? by Björn Fahller

Björn Fahller spoke at C++ On Sea 3 times this year! He volunteered to replace one of the speakers who sadly couldn’t make it to the conference, and he also did a lighting talk.

One of my favourite talks was his presentation about how to use C++’s type system effectively [Fahller23].

No, not because of the great images of jigsaw montages.

No, not because at the end he mentioned my talk from last year as a valuable reference [Dargo22a]. But to be fair, it really touched me. Especially that it was not because I was in the room; it was already mentioned on the references slide.

As I also covered here [Dargo22b], using several bool parameters is both difficult to read and dangerous. But it’s not only about bools. Adjacent parameters of the same type always have the risk of being mixed up.

Instead of relying on good eyes, you might want to rely on the compiler and use enums and classes with descriptive names.

And as Björn said, don’t use type aliases instead of strong types, a type alias is just a comment, nothing more.

An interesting idea he mentioned was how to deal with parameters when you have a bunch of them and many of them would be defaultable. In that case, use a struct, let the members have their default values declared in place and then take advantage of C++20’s designated initializers [Filipek21]!

What a nice idea!

C++ and Safety by Timur Doumler

The topic of safety often comes up in C++. It’s been an important topic for many years, but the topic has become even more prevalent since the NSA wrote that “exploitable software vulnerabilities are still frequently based on memory issues” and recommended that “the private sector, academia and the U.S. Government use a memory-safe language when possible”.

In his talk [Doumler23a], Timur discussed the different forms of safety, and how they relate to correctness. He debunked some myths and shared his view of whether C++ is in trouble or not.

When it comes to safety, we can think about both functional and language safety. When we talk about C++, we are talking about language safety. Language safety can be broken down into memory, thread, arithmetic and definition safety. Timur showed through a set of small and simple examples how much C++ lacks basically any aspect of language safety.

He also showed that even if you have language-safe programs, having a functionally safe, God forbid, correct program is so difficult. In that sense, C++ is not the problem.

But otherwise, how much is C++ the problem? Why did the NSA explicitly target C++?

Those who complain most often speak about ‘C/C++’. Anyone who speaks about ‘C/C++’ shows how little they understand these programming languages. Those are two separate languages!

While it’s true that almost 50% of the reported language vulnerabilities are coming from C, C++ is actually only the 6th on the list, behind languages such as PHP, Java and Javascript. Even Python. (See Figure 2 [Doumler23b].)

Figure 2

C++ took a long journey and is full of safety features and it’s still getting further safety features. Will they be completely safe? No. Will C++ ever be fully safe? No, it’s impossible. As a minimum, language safety would mean no undefined behaviour.

But we need undefined behaviour and we often have to make tradeoffs between safety and performance, portability or cost.

Yet, Timur showed the different strategies we could take to achieve the different kinds of language safety and also shared how viable these strategies would be.

Timur’s conclusion is that C++ mostly has a PR issue. C++ isn’t as behind so many safety issues as many think. Even so, it’s getting safer and many UBs have been or are being removed when this doesn’t compromise performance and compatibility, which are often the main reasons behind using C++.

There is no such thing as a safe coding language. Languages call other languages and even so-called safe languages such as Rust have vulnerabilities. On the other hand, the C++ committee should probably be clearer on its strategy and also on how far we have already come.

An interesting talk with full of easy-to-follow examples!

My favourite ideas

Now let me share a few interesting ideas from three different talks.

Jonathan Müller’s favourite C++ question

Jonathan’s talk would have probably been among my favourite ones if he had 30 minutes more to present the same content. My brain is too slow for interesting ideas coming so rapidly! ☺ He talked about C++ features that are either forgotten or undervalued.

He mentioned many interesting topics, and some I’ll probably write about more deeply in the coming months (I’ll not forget to refer to his talk!), but here I want to mention only one thing.

His favourite C++ question that was originally posted by Richard Smith [Smith19])

  // Assuming an LP64 / LLP64 system,
  // what does this print?
  
  short a = 1;
  std::cout << sizeof(+a)["23456"] << std::endl;

So, what is the output?

The answer requires quite a few steps. I don’t want to go into an explanation in this article: I’d like you to think about it. Here are a few hints:

• What does unary plus do?
• What’s the type of "23456"?
• What does sizeof return?
• What is a little-known characteristic of the built-in index operator?
• What’s the precedence of operations in this expression?

If you are stuck and desperately looking for the answer, check it out on Jonathan’s site [Muller23].

Bryce Adelstein Lelbach thinks we often treat AI unfairly

In his endnote, Bryce talked about his experiments with ChatGPT and how it was helping him create a parallel algorithm.

Listening to him probably made many of us think that oh, okay, it’s hard to use AI-assisted tools effectively, they are still too dumb for this, and they need too many iterations, too many rounds.

But at the end, Bryce reminded us that we are just being unfair towards ChatGPT and other large language models.

Do we expect ourselves to write perfect code on the first run?

Not really, right?

If you post a pull request and someone asks you if there were any bugs in it, would you reply that yes, here they are?!

Not really, right?

ChatGPT et al. cannot write perfect code on the first or second run either, but it can analyse its own code more objectively than you or I could our own code. At the same time, it can iterate on code and write better and better solutions of the same problem.

So, let’s reconsider how we think about them.

Dr. Allessandria Polizzi shared that boredom can also lead to burnout

Even at a conference dedicated to C++, you might find topics that are not necessarily about the language (such as my talk about clean code), or about software development.

Dr. Allessandria Polizzi spoke about mental health. She shared what the main risks are leading to burnout and what best practices are available for us in case we want to guard against it. Burnout is real and it doesn’t simply happen to you, you can prevent it.

There is one risk here that I want to emphasize from her presentation. You might think it’s great when you have a low workload. I think that if you are conscious enough of the issue, it’s not so bad, but according to research, for most people a low workload can lead to burnout faster than a high workload. Not just burnout but even ‘boreout’ is real.

In my opinion, if you have a low workload, take advantage of it. Work on your own initiatives and invest time in learning to get even better at your job.

Nevertheless, it’s important to know what are the different factors that can lead to burnout.

Personal impressions

Finally, let me talk about some more personal feelings about the conference.

C++ On Kaizen

I remember that, even last year [Dargo22c], I appreciated the constant improvements at the conference. I think most of the complaints were about lack of water and long queueing times for lunch. The water problem was solved after the first day, and this year, the queueing situation improved a lot too. In different rooms, talks ended at different times right before the lunch break so that not everybody went to eat at the same time. That was a great idea! But what matters more – to me – is the mindset of constant improvement.

Hard to stay an introvert

By the end of the conference, I felt exhausted, but in a good way. I had inspiring discussions with so many people and I even met someone who went to the same high school as me and finished just one year earlier.

While I’m an introvert and I rarely start conversations with strangers, I tried my best at the conference. And even when I didn’t, as a speaker I often got approached by others.

I was on the phone with my wife and I told her that I had got a baseball cap as a swag, though I’m not sure if I would ever use it. She reminded me that she wears such caps. “Oh I remember,” I said, “you even have the one signed by Charles Leclerc!” At that moment I realized that I could also get some autographs at the conference. Not on a cap, but on the conference T-Shirt which has the name of all the speakers!

By the end, I had a signature from almost anyone. And mine is just next to the signature of the Explorer of Compilers! How cool is that!

Figure 3

My two talks

This year, my topic(s) were not technical. I signed up for a lightning talk, where I shared my findings on how one can improve his or her job hunt experience. After all, I joined Spotify less than a year ago! Such an important topic for everyone!

Thursday afternoon, I got an hour to speak about why clean code is not the norm [Dargo23]! In particular, about what clean code is, what it has to do with software quality and also how it is related to professional ethics.

At the end, there were some good and/or provoking questions and remarks. I was humbled by the ratio of other speakers in the audience, and I received a lot of great feedback. Even if we didn’t agree on everything, my talk was thought-provoking and sparked many discussions.

Conclusion

In this article, I have covered one way that can help you get closer not only to attending but to speaking at conferences. In my opinion, this is way better than just attending, because often (most of) your costs will be covered, you’ll learn way more and build more connections. Not to mention that it’s easier to convince your management to let you speak at a conference than to buy you a ticket and finance the trip.

C++ On Sea was once again an awesome experience! Great organization, a strong line-up and awesome attendees! I hope I can be back in Folkestone in 2024.

Connect deeper

If you liked this article, please

• hit on the like button on the original post
• subscribe to my newsletter (http://eepurl.com/gvcv1j)
• and let’s connect on Twitter (https://twitter.com/SandorDargo)!

References

[C++OnSea] The C++ on Sea website: https://cpponsea.uk/

[Dargo22a] Sándor Dargó ‘Strongly Typed Containers’ presented at C++ on Sea 2022, available at https://www.youtube.com/watch?v=0cTOqwrvq94

[Dargo22b] Sándor Dargó ‘Use strong types instead of bool parameters’ posted 5 April 2023 at https://www.sandordargo.com/blog/2022/04/06/use-strong-types-instead-booleans

[Dargo22c] Sándor Dargó ‘Trip Report: C++ on Sea 2022’, posted on 26 July 2022 at https://www.sandordargo.com/blog/2022/07/27/cpp-on-sea-trip-report

[Dargo23] Sándor Dargó ‘Why clean code is not the norm?’ (abstract) available at https://cpponsea.uk/2023/sessions/why-clean-code-is-not-the-norm.html

[Doumler23a] Timur Doumler ‘C++ and Safety’ (abstact) available at https://cpponsea.uk/2023/sessions/cpp-and-safety.html

[Doumler23b] Timur Doumler ‘The C++ Undefined Behaviour Survey’, posted on Timur.Audio on 14 April 2023 at https://timur.audio/

[Fahller23] Björn Fahller ‘Typical C++, But Why?’ (abstract) available at https://cpponsea.uk/2023/sessions/typical-cpp-but-why.html

[Filipek21] Bartlomiej Filipek ‘Designated initializers in C++20’ posted on the C++ Stories blog: https://www.cppstories.com/2021/designated-init-cpp20/

[Hinnant20] Howard Hinnant ‘How I Declare My class And Why’, posted 24 February 2020 at https://howardhinnant.github.io/classdecl.html

[Muller23] Jonathan Müller ‘C++ Features You Might Not Know’ (slides and video) available at https://www.jonathanmueller.dev/talk/cpp-features/

[Smith19] Richard Smith, quiz question posted on Twitter on 18 March 2019, available at https://twitter.com/zygoloid/status/1107740875671498752?lang=en

[vanRens23] Kris van Rens ‘Special member functions in C++’ (abstract) available at https://cpponsea.uk/2023/sessions/special-member-functions-in-cpp.html

This article was published on Sándor Dargó’s blog in July 2023 and is available at https://www.sandordargo.com/blog/2023/07/05/trip-report-cpp-on-sea-2023.

Sándor Dargó is is a passionate software craftsman focusing on reducing maintenance costs by applying and enforcing clean code standards. He loves knowledge sharing, both oral and written. When not reading or writing, he spends most of his time with his two children and wife in the kitchen or travelling.