Notes, talk summaries, trip reports from Cpp Con 2017
published at: Bartek's coding blog: Cpp Con 2017 Notes
Links
-
Quentin Duval - My CppCon 2017 Trip Report – 10 great talks to watch and learn from
-
Patrice Roy - À propos de cppcon 2017 in french
-
IT Hare on Soft.ware reports:
-
#CPPCON2017. Day 1. Hope to get something-better-than-chevron-hell
Here's a list of talks with a summary and they key points.
CppCon 2017: Bjarne Stroustrup “Learning and Teaching Modern C++” - YouTube
- "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).
CppCon 2017: 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
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.
CppCon 2017: 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
- 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.
-
Conan.io is a portable package manager that helps in dependencies management. It provides package versioning, local binary cache, package server and integration with JFrog - artifact repository.
-
Conan.io can be easily integrated with Jenkins pipeline. Packages can be built, tested and uploaded to artifact repository using Jenkinsfile .
- Move semantic is good but loud.
clang-tidycan detect use after move.- Why we stuck at C++11 again? It's 2017.
-
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.
-
Writing framework
- Introduction - purpose of the library
- Motivating examples with explanation
- Notes
- Rationale
- Reference
- Concepts (type requirements): why this type parameters we have to use
- Types
- Functions
- Metafunctions
-
Tools
- Doxygen
- Doc in comments
- ugly and hard to configure
- hard to write concepts and examples
- Docbook/BoostBook
- 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
- Doxygen
-
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 ).
-
Documenting tools:
-
Mocks/stubs are needed when:
- real object has nondeterministic behavior,
- real object is difficult to set up,
- it is hard to trigger behavior on real object,
- real object runs slow,
- real object is not implemented yet,
- want to check the correctness usage of real object.
-
Seams is a place where you can alter behavior in your program without editing in that place. There are 4 types of seams:
- object seam,
- compile seam,
- preprocessor seam,
- link seam.
-
Problems with C++ mocking frameworks:
- some implementations are modeled on Java designs,
- no useful reflection implies usage a lot of macros for generating names, defining function stubs, etc.,
- some implementations relies on ABI, replacing vtable entries - not portable and not compatibile between compiler versions - more about replacing vtables you can find here
- Domain Specific Language (DSL) used to define (expected) behavior is not understandable for refactoring tools,
-
Overusing mocks can cause tight coupling between test case and System Under Test (SUT), and SUT with Dependent Other Components (DOC).
-
General thoughts about mocking:
- mocks are good for testing legacy code, non-changeable stateful API,
- be aware of mocking for new, premature code or unwritten code,
- test cases should be as simple as possible.
-
Mocking frameworks/tools:
- (author) Bartek from bfilipek.com
- Łukasz Rachwalski - organizer of C++ User Group Krakow
- Yann Labou
- Erick Guan