Category: C/C++

CppCon is an annual, week-long conference for the entire C++ community. Every year thus far, it’s been held at the Meydenbauer Center in beautiful Bellevue, Washington. It’s a young conference. This year marks only its third year. But the scale of the whole thing has allowed it to easily set itself apart from other C++ conferences. It’s huge.

This year, there were well over 900 attendees.(Edit: I had originally stated a 50% growth figure, which Jon Kalb pointed out was very wrong. Whoops! Sorry about that. Thanks, Jon! CppCon continues to grow, however!) The weekend leading up to conference is full of classes. And the weekdays are jam-packed with content, with sessions starting as early as 8AM and running as late as 10 at night. This year, there were typically six to seven tracks of sessions happening at the same time.

There’s always plenty to do and experience at CppCon. And it’s not always easy to decide on where to spend your time. Fortunately, all of the regular sessions are professionally recorded. So if you miss something, chances are you’ll be to find it on YouTube later on (the exceptions being classes, open content sessions, some lightning talks, etc.)

New This Year

There were a few things new at CppCon this year.

Last year, the committee experimented with a class offering for the weekend leading up to the conference. The class was such a success that they decided to expand the menu to five for this year.

Early-bird registrants got free CppCon t-shirts. This was a first for the conference.

This was also the first year they attempted a poster contest at CppCon. I believe there were only 4 posters submitted for this year. But this number will surely grow for next year, as attendees now know what to expect.

Session Stand-Outs

CppCon kicked-off with a keynote from Bjarne Stroustrup regarding the state of C++, how it got to be where it is today, and where it’s going. During this talk, Bjarne became uncharacteristically aggressive towards the C++ standards committee concerning C++17. It was clear that he was dissatisfied with the lack of progress made towards standardization of such features as concepts, modules, co-routines, etc. And it appears to me that the community as a whole sides with Bjarne on this matter. I counted at least ten, perhaps more, talks on features that are either in technical specification or in proposal status.

These were the sessions that really stood out for me this year.

Howard Hinnant’s “A <chrono> Tutorial” was a superb introduction to std::chrono. I have to confess that I’ve struggled to use this library effectively. It always frustrated me at how much code and how many data structures are involved in order to do the most basic of time-based calculations. Howard’s presentation changed my view of std::chrono entirely and made me realize that more often than not, I was just using std::chrono all wrong. 🙂

An interesting tidbit that came out of this discussion is that std::chrono’s epoch isn’t specified by the standard. I had (wrongly) assumed that it was always Jan 1 1970, just like that used by the time() function. Stephan Lavavej, who happened to be in the audience, spoke up and stated that the Microsoft VC++ implementation of std::chrono is changing its epoch to January 1, 1601, which is consistent with the Windows NT epoch. (Edit 2016/10/10: As Howard Hinnant notes in a comment below, this decision has been reversed by the VC++ team. Howard is currently working on a proposal to standardize the system_clock epoch to Jan. 1 1970.)

Timur Doumler’s “Want Fast C++? Know Your Hardware!”, was also an eye-opening talk. It was all about code organization and how it can affect performance, especially as it relates to the cache. After this talk, I’ll never look at reinterpret_cast the same. Timur is an audio guy. And audio is an area where performance really matters. Every talk I’ve seen of his has been wonderful. If you haven’t seen his CppCon 2015, JUCE Summit 2015, or BoostCon talks, I strongly recommend checking them out (in that order).

Jason Turner gave two solo talks at CppCon this year that were fantastic. “Rich Code for Tiny Machines: A Simple Commodore 64 Game in C++ 17” and “Practical Performance Practices” were both about performance. Throughout both of his presentations, he used the Godbolt Compiler Explorer to demonstrate the impact simple language features can have upon the resulting assembly code. Everything he discussed revolved around the premise that less instructions = faster code, so you didn’t really need to understand assembly to appreciate his talk.

Other sessions that I enjoyed were Tim Shen’s “Regular Expressions in C++, Present and Future”, Steve Carroll and Daniel Moth’s “Latest and Greatest from the Visual Studio Family for C++ Developers”, James McNellis’ “An Introduction to C++ Coroutines”, Dan Saks’ “extern “C”: Talking to C Programmers about C++”, Rob Irving and Jason Turner’s “What We’ve Learned from the C++ Community”, David Sankel’s “Building Software Capital”, Miodrag Milanovic’s “The MAME story: From C to Modern C++”, and Any Bondy’s “AAAARGH!? Adopting Almost Always Auto Reinforces Good Habits!?”

Conclusion

I’m sure there were many other stand-out sessions from other presenters. With so much going on at the same time, it’s impossible to not miss out on something fantastic. Once the videos are posted on YouTube, I’m sure I’ll stumble across more than one thing that I’ll kick myself for missing.

There were some faces that were notably absent this year, such as Andrei Alexandrescu, Scott Meyers (retired from the C++ scene, but I still hope to see pop up from time to time), and Peter Sommerlad. There were also a few people who I enjoy listening to that were present, but didn’t speak (Titus Winters, I’m talking about you).

All in all, 2016 was another great year for CppCon. If you’re a C++ programmer and have the opportunity to attend this conference, you should definitely go.

Recent trip reports (1,2) from the February/March C++ Standard Committee meeting revealed a few details concerning the upcoming C++17 standard. It looks like a number of features, including modules, concepts, ranges, and coroutines won’t be making it in. If you’ve paid attention at all to the C++ community over the past year or two, you’ll know that these were some of the things that folks were most excited about. For a long while, there was a sense that these features were a done deal. They garnered a lot of buzz even before C++14’s paint dried. Talks have been given on them. Blogs have been written about them. Compiler vendors jumped on the bandwagon and started releasing early implementations for community review. The C++ train has had a lot of momentum, so the expectations were high. And now I suspect that many C++ aficionados are feeling a tad bit jilted.

Truth is – I’m kind of relieved.

We’ve come a long way since C++98. There have been significant improvements to the language. I can’t deny that. But with the good comes the bad, or at the very least the not-so-great. Every time a new standard is released, we get more cruft, more weird keywords, and more things that don’t feel like C++ (You thought the square bracket lambda syntax was weird? Wait until you get a load of the annotations coming in C++17!). With every new standard, the learning curve gets a bit steeper.

A couple of years ago, Mike Acton made the offhand remark in his CppCon 2014 talk “Data-Oriented Design and C++”(23:35), “I can just imagine this meeting tonight on, you know, what else can the C++ committee add to the fucking lang, er, add to the language to make it solve our problems for us, right?” It was funny. I laughed. And I totally agreed with the spirit of what he was saying.

The C++ Standards Committee has, as a matter of principle, strived to maintain backwards compatibility with each iteration of the C++ standard. It’s an honorable goal, and one I think is important. Certainly, some of the largest and oldest active codebases in the world are written in C++. So for many, breaking language changes would be a non-starter. But how do you evolve a language and keep its complexity manageable without removing something? Perhaps you can’t.

Scott Meyers suggested in CppCast Episode #26 that maybe it’s time to finally remove obsolete language features. It’s an interesting idea. But it should send a shiver down the spine of any developer who’s had to maintain a large, legacy codebase. Add in the need to support multiple platforms and compilers, things get even scarier. It’s a path rife with compiler divergence and inconsistencies. Maintaining code would only get harder. It’s a direction that I think is unpalatable for most. Not to mention at what point is C++ no longer C++?

So time will march on and C++ will continue to have, as it always has, a reputation for being complicated. Since C++11, a new standard has been released every three years. Herb Sutter’s C++17 trip report mentions the committee is considering shortening the release cycle to two years, promising bigger, better, faster, stronger. And messier.

I’m slightly discouraged by the whole thing. In an era when it’s common to build applications using a heterogeneous assortment of technologies, why does C++ feel the need to become everyone’s everything language?

Engineers are in the business of getting things done. We strive for elegant, simple solutions that clearly communicate our ideas and that are easy to maintain. For C++ developers, it’s unfortunate that the complexity of our tool is overshadowing the work we do. Most folks don’t have the time and energy to keep up with the language changes. Those folks are in the trenches, hard at work building real applications. The irony here, of course, is that these are the very folks the latest and greatest language features were intended to help.