Table of Contents

This year I had a chance to visit Wroclaw for the 4th edition of Code Dive! Two days of a great programming conference!

Briefly: many of topics related to C++, two days, 40 presentations, lots of people and a beautiful city. What more do you need? :)

Continue below to read my report from the event.

Intro  

The conference took place in “Kino Nowe Horyzonty”, Wroclaw on 14th and 15th November (Tuesday, Wednesday).

The venue was a cinema in the centre of the city. Watching a talk was a pleasurable experience, as you got a comfortable seat and no one would cover the view in front.

I was in the first edition of the event, in 2014: see my report here. And at the end of that post I wrote:

Great conference and I would love to attend next year. I hope Nokia (or maybe others sponsors) will decide to host this event in 2015 as well.

And fortunately, Nokia decided to continue doing the conference. Many thanks!. We don’t have many (or even any!) C++ conferences in Poland, so Code::Dive serves an important role here.

Here’s the main site where you can check the details:

code::dive

Their youtube channel:

code::dive conference - YouTube

And Twitter:

code::dive (@code_dive_pl) | Twitter

Please track the youtube channel. Hopefully, in the next few days, we’ll see the recorded versions of the talks. At the moment you can just watch saved live streams, but only from one of the fourth tracks.

code::dive 2017 conference - day 1 - YouTube

2016 edition:

http://codedive.pl/index/year2016 (links to slides, videos, etc)

Day 1 presentations  

John Lakos: Value semantics: It ain’t about the syntax!  

To be honest, I’ve seen only a part of this presentation… on a live stream while travelling via bus to Wroclaw :)

You can see it also through the youtube link: code::dive conference day 1, but the same talk can be seen in many other places. For example:

CppCon 2015: John Lakos “Value Semantics: It ain’t about the syntax!, Part I” - YouTube and

CppCon 2015: John Lakos “Value Semantics: It ain’t about the syntax!, Part II” - YouTube

While I’ve seen only the first 40 minutes, it’s a good thing for me because it’s a really “heavy” talk. It’s probably a good idea to watch it a few times, with some breaks.

Just a few words about John: he’s the author of Large-Scale C++ Software Design - a book from 1996, but still very valid! He works for Bloomberg in New York, and he’s also an active member of C++ Committee.

The core concepts of the talk:

  • The presentation talks about value types and various categories of them. Probably we all feel what a value is, but John went further into real Information Theory and Mathematics to show important aspects.
  • C++ types/objects are only a representation of mathematical entities. For example type int represents only an approximation of the mathematical integer type.
  • Salient attributes - attributes of a type T that contribute to its value. If all salient attributes have the same value, then we can say that two objects of type T have the same value. We don’t care about the representation, internal implementation here.
  • For example in std::vector we care about values of individual objects in the container and the size of the container. But capacity is something internal.
  • Why unique values are important: because we might want to transfer the same value to other processes and still be able to understand and compare it. For example: store a Date record in a database.

What’s more John mentioned that he has finished working on the text for his upcoming (and delayed) book: Large-Scale C++ Volume I: Process and Architecture. It supposed to be released in 2014 as far as I remember, but it was constantly pushed. But at least there’s hope for Spring 2018 :)

Alex Crichton: Concurrency in Rust  

I got at this talk by accidence! :)

I was late and wanted to go to Andrzej Krzemieński talk about undefined behaviour. But the room was full, and I couldn’t enter. So I decided to see what’s Rust all about!

Alex Crichton, the presenter, https://github.com/alexcrichton, is a Staff Research Engineer at Mozilla and has been working on the Rust programming language for 5 years.

Sadly, the Alex’s another talk - “Introduction to Rust” was scheduled for the second day. So all in all, it was a too advanced and complicated topic for me to understand - as I am not experienced with the language.

Maybe I didn’t get all of the things, but still I noted a few important aspects:

  • Rust might be designed as a competitor to C++, and it’s also native language. Still no-one can tell me that it’s much easier than C++
  • I like borrowing, ownership and lifetime concepts; this guarantees safety. The disadvantage: it sounds complicated! We have something similar in C++, but I feel in Rust it’s more ‘explicit’, with more techniques to use.

Mark Isaacson: Exploring C++17 and Beyond  

Mark Isaacson is a Software Engineer at Facebook, where he works on improving the developer experience for all C++ programmers at Facebook. He’s also the author of:

Modern Maintainable Code Blog

The presentation can also be found here:

http://maintainablecode.logdown.com/posts/745037-tech-talk-exploring-c-17

Some notes:

  • Mark went quickly through the list of new features but stopped on three things:
    • string_view
    • operator dot (future thing, might even not go into C++20)
    • constexpr if
  • With the first topic - string_view he showed a few examples where might it help. For example it’s good when replacing const char* global/static values.
    • But, on the other hand, we need to understand that it’s only a view, we don’t own the memory. So string views should be used with care
  • Operator dot N4173 - a paper from 2014, might be outdated. An interesting thing that could expose the underlying members through only one additional operator. Could be handy for pimpl idiom.
  • constexpr if - I liked the comparison about template metaprogramming. For most of the people, it’s a complete magic. All of crazy things that are needed to write an if (like tag dispatch or SFINAE). With constexpr if we can just write if. So it’s reducing that magic.

Andreas Weis: Howling at the Moon: Lua for C++ Programmers  

Andreas works in BMW, and he’s also a co-organizer of C++ Munich Group.

Shorter version of the talk (we had 60 minutes)

CppCon 2017: Andreas Weis “Howling at the Moon: Lua for C++ Programmers” - YouTube

Slides for the talk

My notes:

  • Lua (@wiki) is used mostly for gamedev, but other apps might also use it. For example Adobe Lightroom, some Arduino? boards.
  • Designed at university in Brasil
  • It’s designed as embeddable language. So it’s much lighter than other languages that could be used as a separate language (for example like Python, javascript)
  • Very small and relatively fast
  • The talk describer the basics of the language and how can it be integrated into C++ app
  • Andreas presented a few examples where C++17 shines:

for example: fold expressions

// Pushing values on the stack, `push` for each type
void  push(lua_State* l, lua_Number n) {
    lua_pushnumber(l, n);
}
void  push(lua_State* l, char  const* s) {
    lua_pushstring(l, str);
}

// fold:
template <typename ... Ts >
void  pushargs(lua_State* l, Ts...  args) {
    ( push(l, args), ... );
}

Or using std::variant to represent all 8 possible types that Lua support.

A good example to read and understand how modern C++ might help!

Łukasz Langa: Thinking in coroutines  

Another mistake?

Hmm… I didn’t read the notes/description under the talk, and I though it’s about C++ coroutines… but it was Python! :D

For a while, I considered leaving the room, but the presentation was started very light, and with energy, so I decided to stay.

Co routines are a generic concept, so maybe that knowledge would help me in C++ as well?

But to be short, it all looks nice, and we can do a lot of powerful things using co-routines. Still it requires to shift thinking, so might be hard at fist.

Day 2 presentations  

John Lakos: Local (“arena”) memory allocator  

For now you can watch this talk:

Local (arena) Memory Allocators - John Lakos [ACCU 2017] - YouTube

Notes:

  • We have local, global and general/special purpose allocators.
  • By using proper types we might get an order of magnitude in performance!
  • In C++17 we get polymorphic allocators
  • I still need to dig further and understand what’s that all about and how can we use it
  • John presented various benchmark results and commented why something might be faster/slower.
  • Huge potential, but not all devs/projects care about it

Eric Niebler: Introducing the Ranges TS  

Eric Niebler is a senior engineer at Facebook and an active member of the ISO C++ Standardization Committee. He is the principal author of the upcoming Ranges TS and of the range-v3 library on which it is based

http://ericniebler.com/

Ranges TS N4685, Working Draft, C++ Extensions for Ranges will be published in a few days, and I was surprised that this paper is relatively “simple” (although 180 pages :))! We won’t get all that things that we think “Ranges” are: like views, generators.

Still we’ll get the core and crucial parts:

  • background for Concepts (as Ranges are based on Concepts)
  • callable objects
  • The addition of new concepts describing range and view abstractions; that is, objects with a begin iterator and an end sentinel
  • Analogues of the Standard Library algorithms specified in terms of the new concepts.
  • plus some more

So this will 99% go into C++20. Now Eric works on the stuff that is based on that core functionalities. Depending on the speed it might also went into the new standard. Maybe even as STL2?

On this presentation, Eric also showed some other powerful ideas like:

  • Ranges TS with Parallel TS (on GPU!) - using SYCL implementation.
    • Some experiments showed even being faster as handwritten CUDA code!
  • Ranges and coroutines
    • Being async
    • Reactive programming in C++

Mark Isaacson: Developing C++ @ Facebook scale  

Mark’s blog post

Slides: PDF

Notes:

  • In a huge code base (like Facebook’s) your commit might break work for hundreds of other developers. How to mitigate it?
  • How flaky tests might affect build/tests results. How to separate such flaky tests
    • updating test runs with more data, like by using folly::symbolizer::installFatalSignalHandler
  • Automatization of code review
    • Use existing tools: like clang format (to avoid coding style wars! :))
    • running ASAN/Sanitizers tools for checking memory safety, undefined behaviour, etc

Good questions we should be asking in a healthy project:

  • How do you prevent code from breaking?
  • How do you define “broken”?
  • How do you know if something broke?
  • How do you figure out why something broke?
  • Who do you talk to when something breaks?

Takeaways  

  • Other languages are also hard! So C++ is not the only language that is sometimes complex and hard to learn.
  • A lot of programming aspects (like coroutines, reactive programming, etc) is common to all languages. It’s worth to know the differences, or just be aware that other languages also tried to solve some problems.
  • Automate the code review process!
  • Coroutines are getting very popular, in many languages

After one talk I’ve also heard (from the participants) quite important sentence, it sounded more or less like: “C++17 and beyond is so off the ground”… So basically we can talk about nice and shiny things, but normal C++ coding is so much different. Some companies haven’t even moved to C++11.

What’s more, while travelling back home, I generated around 20 ideas for my new blog posts. I need to sort them out and I plan to start writing the content.

Summary  

While I treat Code::Dive as C++ conference it’s probably not how it’s designed. There are other languages that took great deal of the talks: Go, Rust, Java, Python, AR, IoT… so I might better change my view to “a native programming conference”. Still, lot’s of benefits for me.

I hope to visit Wroclaw next year :)

Have you been at Code::Dive this year?
Share your thoughts about this even in the comments!

BTW: check out Code::Dive report from Adi Shavit: code::dive Trip Report @videocortex.