Cpp Con 2017 Notes
Table of Contents
Have you been at Cpp Con this year?
I haven’t, but still I plan to watch some good C++ talks. Can you help me a bit and add your notes?
Last update: 14th October 2017
Cpp Con 2017 is over and recently the videos from the talks started to appear. It’s a good time to refresh the knowledge about C++ and learn something new. I am especially interested in talks about new things, industry problems and experience with using C++ in production.
I am using open repository to collect notes, so just follow: github/fenbf/cppcon2017_notes. Submit your changes so we can make a larger collaborative post.
First of all here are the official links:
And the summary:
Thanks / 2018 Dates / 2017 Trip Reports | cppcon
And some of the trip reports:
Patrice Roy - À propos de cppcon 2017 in french
IT Hare on Soft.ware reports:
- #CPPCON2017 Day 0: IMO best posters
- #CPPCON2017. Day 1. Hope to get something-better-than-chevron-hell
- #CPPCON2017. Day 2. Why Local Allocators are a Good Thing(tm) Performance-Wise, and Why I am Very Cautious about C++17 STL parallelized algos
- #CPPCON2017. Day 3. The Future of C++
- #CPPCON2017. Day 4. Async Rulezzz!
- CPPCON Day #5. Miscellaneous
Here’s a list of talks with a summary and they key points (to be updated!)
Bjarne Stroustrup “Learning and Teaching Modern C++”
- “We’re all teachers” - this is a good talk, especially for all the people who teach other how to code: but not only bloggers, proffesors… but even for you when you advice/help your collegues from time to time.
- C++ was tought sometimes in a messy way, so we can do better.
- “if you write your own linked list (and use it in production code) you’re cool”. We cannot teach that way any more. It’s just better to use STL.
- Simple example: Why range for loop is better than the old for loop (with i as the index).
Matt Godbolt “What Has My Compiler Done for Me Lately? Unbolting the Compiler’s Lid”
- Matt’s story: why he loves asm and how he started with Compiler Explorer.
- ASM 101, it’s really not that hard to read some of the basic code. It might help you to understand your code better.
- Examples of how compilers might be smart. Math stuff mostly, but intresting to see how it’s usually best to rely on the code generation.
- Tech stack behind Compiler Explorer
Herb Sutter “Meta - Thoughts on Generative C++”
At the beginning of the talk, Herb Sutter smartly “smuggled” very interesting concept of “Consistent comparison” in C++ which details you can find in proposal material P0515 R0.
Main part was based on C++ static reflection – many links about this
topic you can find on
Jens Weller site. Herb shown how C++ can be easily extended using meta-classes that introduce another kind of abstraction. That was announcement of great changes that will come in near future.
Carl Cook “When a Microsecond Is an Eternity: High Performance Trading Systems in C++”
- High Frequency Trading in general earns money by buying and selling
very often, and looking for small price changes. The success is to
be faster than the competition.
- Usually they have like 2.5us to react and do the trade… it’s less time than a light travelling from top of BBurj Khalifa to the bottom!
- C++ is used because it’s a relatively abstract language, gives zero
cost overhead over the abstraction over the hardware.
- They often have to check the generated code, so it’s no coincidence that Compiler Explorer comes from that industry… check Matt’s talk.
- Techniques covered (for the hot path, not for the whole code)
- removing branch prediction, using templates and compile time configuration (to avoid dynamic polimorphism, virtual method costs, eliminate branches)
- Lambdas are very expressive and still give a lot of power, they might be inlined.
- Be carefull about memory allocations, use pool of pre allocated objects, delete on other thread
- Carl advices to use exceptions (but not for the control flow!), they cost zero if they didn’t throw.
- Multithreading is usually avoided for low latency code, the hot path. They even disable all other cores and use just one.
- Use data wisely, if you read something from the memory, use full cache lines
- There’s a comparision of various hash map approaches
- in order to keep the cache hot, they might run simulations and only from time to time do the actual trade/response.
- As usually: measure measure measure :)
- They setup a production system to measure it reliably
Scott Wardle “EA’s Secret Weapon - Packages and Modules”
- 15 years ago ElectronicArts faced the problem of code sharing and versioning. The company with many departaments around the world and code base running on multiple platforms decided to use code level, package approach.
- A package is a C++ library source code conatining package name, package version, public includes (interface) and private includes and sources.
- Masterconfig file specifies list of all packages and versions ( including coinstraints ) on executable/project/team level.
- Each EA team build the packages on its own using configuration packages containing building flags.
- Packages are uploaded to package server, while source code is stored independently on VCS.
- Both packages and modules deals with public interfaces and hiding privates.
Diego Rodriguez-Losada Gonzalez “Faster Delivery of Large C/C++ Projects with Conan Package Manager and Efficient Continuous Integration”
Both inline functions ( declared in headers ) and archive ( static library ) functions used
in shared library cause that the code is totally embedded into shared library. Any change the
code of static library or header function without rebuilding shared library cause code and behavioral divergence.
Roel Standaert “Migrating a C++03 library to C++11 case study: Wt 4”
- Move semantic is good but loud.
clang-tidycan detect use after move.
- Why we stuck at C++11 again? It’s 2017.
Robert Ramey “How to Write Effective Documentation for C++ Libraries with Minimal Effort”
Be descriptive in the first paragraph for library doc.
Writing doc is hard. The tool only helps a little.
Writing doc with code.
- Explicit state the intended purpose.
- Code should reflect that intention.
- Should address only public API, exclude anything else.
- Implementation notes in the code.
- Introduction - purpose of the library
- Motivating examples with explanation
- Concepts (type requirements): why this type parameters we have to use
- + Doc in comments
- - ugly and hard to configure
- - hard to write concepts and examples
- + decouples content from format
- - gen/edit XML is hard
- QuickBook is the rescue for Boost authors
- XMLmind (Robert’s recommendation)
- WYSIWG for boostbook
- enforce Boostbook syntax
Code implementation and documentation should be updated at the same time.
Documentation helps users to use the code. It should state the purpose of the code and address only public API.
Anything else can be excluded. Implementation notes should be in code.
Exemplary documentation can have the following sections: Introduction, Motivation examples with explanation, Notes, Rationale, Reference ( Concepts, Types, Functions, Metafunctions ).
- (author) Bartek from bfilipek.com
- Łukasz Rachwalski - organizer of C++ User Group Krakow
- Yann Labou
- Erick Guan
Do you have notes from other talks? Just fork the repository and send me a pull request! :)
- C++ Status at the end of 2016
- C++ Status at the end of 2015
- OpenGL 4.5
- Talk summary: The Last Thing D Needs by Scott Meyers