Trip Report: CppCon 2014

I just posted my CppCon trip report over at isocpp.org.

I’ll repeat just the last part here:

Huge thanks again to the 150+ speakers, planners, and volunteers without whom this wonderful “C++ festival” (as several people spontaneously called it) would not have been possible. I had guardedly high hopes for the event, but I think it exceeded all our expectations. This was the most exciting and enlightening week I’ve experienced in my 20 years of C++, and I’m still catching my breath. I can’t wait until September 2015.

Here are a few pics I and others took. You’ll find more on Twitter tagged #cppcon.

Mark Maimone of NASA and Mars Rover fame.

Bjarne taking questions after his talk.

“We’re sold out of A Tour of C++ again… how about this instead?” [photo credit: Artur Laksberg]

[photo credit: Artur Laksberg]

[photo credit: Artur Laksberg]

Walter Brown speaking in one of the six concurrent breakout sessions.

Jon Kalb speaking in one of the other rooms.

Possibly the youngest attendee? [photo credit: Artur Laksberg]

Accessibility and community.

Yup. Modern C++.

View from the CppCon balcony before diving into more evening sessions.

So long, Meydenbauer Center… see you next year! [photo credit: Hyrum Wright]

9 thoughts on “Trip Report: CppCon 2014

  1. Just watched “Back to the Basics! Essentials of Modern C++ Style”. Although I generally enjoyed the talk, I have a couple of comments.

    The first is about inout parameters should be using refs. I tend to agree with Google’s style that there should never be any non-const ref paramaters because it isn’t obvious when using a function with a non-const ref parameter that it may modify that parameter since the call looks the same as if it were passed an in parameter.

    That being said, the logical “fix” to use pointers for inout parameters is also imperfect because it introduces two side-effects:
    1) pointers can be null while references cannot which adds ambiguity the the method signature because this may be an optional parameter (Can I pass null?)
    2) the parameter can be confused with an out parameter. Although it could be argued that out parameters should be replaced with return tuples + tie().

    That’s one of the shortcomings of C++ where it’s non-trivial to show usage intent of parameters that languages like C#, D etc. have long fixed by introducing keywords.

    The second is about always return by value. The same argument that was made for not passing arguments by value to sink functions (not efficient when used in a tight loop because you can’t reuse instance for strings and vectors) also applies to returning by value. I feel the talk should have addressed this case as well.

  2. @pauljurczak I think that would be a bad idea, because then typos would accidentally declare new variables and the code would silently ‘work’. There are languages that do this and they are not suitable for large programs in part due to this problem.

  3. It looks like something ate the code between angle brackets, so here is the plain text version of my post:

    I enjoyed watching your “Back to the Basics! Essentials of Modern C++ Style” presentation where you advocated almost always using “auto” in declarations. How about following this and Occam’s razor idea to its logical conclusion and skipping redundant “auto” altogether. The first use of a variable on the left side is it’s declaration, as if there was an “auto” preceding it. Is this a completely silly idea?

  4. I enjoyed watching your “Back to the Basics! Essentials of Modern C++ Style” presentation where you advocated almost always using in declarations. How about following this and Occam’s razor idea to its logical conclusion and skipping redundant altogether. The first use of a variable on the left side is it’s declaration, as if there was an preceding it. Is this a completely silly idea?

  5. Herb,

    I asked a question related to something you covered in one of your CppCon talks over on stackoverflow.com

    http://stackoverflow.com/questions/26147491/whats-the-correct-enable-if-constraint-on-perfect-forwarding-setter#26149100

    During the discussion it became apparent to me that it’s not clear if you intend your perfect forwarding set_name() function to accept string literals or not. I started out with the impression that you did want to accept string literals, but on further viewing I notice that you never actually say that.

    So, did you intend the following to work, or do you have some reason to disallow it (perhaps the reason outline by one of the stackoverflow answers)?

    employee e;
    e.set_name(“Bob”);

  6. If I remember right they said video recordings would be available within a month or two. They are likely to be announced at cppcon.org when available.

  7. Should have posted your dance video, too. It is an instant success on FaceBook :). More viral than the iCloud leaks. ;)

Comments are closed.