Topics

Featured in Development

As part of our core values of sharing knowledge, the InfoQ editors were keen to capture and share our book and article recommendations for 2018, so that others can benefit from this too. In this second part we are sharing the final batch of recommendations

Featured in Architecture & Design

Tanya Reilly discusses her research into how the fire code evolved in New York and draws on some of the parallels she sees in software. Along the way, she discusses what it means to be an SRE, what effective aspects of the role might look like, and her opinions on what we as an industry should be doing to prevent disasters.

Featured in Culture & Methods

Mik Kersten has published a book, Project to Product, in which he describes a framework for delivering products in the age of software. Drawing on research and experience with many organisations across a wide range of industries, he presents the Flow Framework™ as a way for organisations to adapt their product delivery to the speed of the market.

Featured in DevOps

The fact that machine learning development focuses on hyperparameter tuning and data pipelines does not mean that we need to reinvent the wheel or look for a completely new way. According to Thiago de Faria, DevOps lays a strong foundation: culture change to support experimentation, continuous evaluation, sharing, abstraction layers, observability, and working in products and services.

Herb Sutter on Modern C++ Essentials

C++ is a complex language, admits Herb, though it must not be complex for every programmer. Herb suggests a view of C++ whereby only a tiny subset of all programmers should concern themselves with the most arcane aspects of the languages, e.g. when dealing with low-level or library code, while all others can just use it in some "default" way that just works.

First case in point is preferring the use of range-for loops. Indeed, while you can write:

for (auto i = begin(c); i != end(c); ++i) { ... }

in modern C++, an easier way of doing the same is:

for (auto& e : c) { ... }

which also provides greater readability.

Pointers, references, new, and delete

Another strong suggestion of Herb's is not using owning *, new, or delete, except when encapsulated inside the implementation of low-level data structures. What is to be preferred to that is unique_ptr, or when you know you are going to share the object, shared_ptr. So you can easily write:

auto p = make_unique<widget>();
auto q = make_shared<widget>();

By using make_unique and make_shared you do not even need bothering about delete.

However, non-owning* and & are still a great resource and their best use case is for passing parameters into functions. What Herb considers a real anti-pattern is using any kind of reference counted variable to pass parameters. This will only be the possible cause for performance problems and should be used only when you want to transfer the ownership of the wrapped object.

Prefer auto to declare local variables

The auto keyword is one of the biggest features of modern c++, according to Herb. auto can be used to deduce a type, but is can also be used to specify a type and stick to it. In you consider the following statement:

auto i = v.begin();

this will correctly deduce the type to be used. This is much easier than the following and goes without much thinking:

vector::const_iterator i = v.begin();

which specifically requires thinking about using a const_iterator.

Correctness is the biggest advantage of auto, but it is also beneficial on other accounts:

Maintainability: it makes the code adapt to changes in, e.g., the return value of a function.

Performance: as a corollary of correct type deduction, auto also guarantees that no temporary objects are inadvertently created, e.g. when initializing an object.

Usability: in special contexts, such as lambda, auto is an enabling factor.

Typing convenience: it allows to save a few keystrokes.

There are though a few cases where you cannot use auto, namely when you are dealing with C-arrays or with types that are not moveable or not cheaply moveable, e.g.:

A large part of the talk is devoted by Herb to discussing parameter passing. His main point here, is that C++98 defaults are still valid in modern C++ and represent a great starting point, with some additional possibilities offered by rvalue optimization. By way of an example, what you should do always is:

On the other hand, Herb suggests to use passing by value mostly in constructors. In other contexts, passing by value, while allowing rvalue optimization, can exact a big performance toll when you pass in a named parameter (i.e., not a temporary object), which would be copied over.

Tuples

Herb's final suggestion regards the use of tuples to return multiple values:

Besides stressing the importance of defaults and idioms, Herb also suggests to avoid overthinking, which generally leads to solutions that are overly obfuscated. On all accounts, his recipe is sticking with what the language offers at the most basic level and then measure to look for areas where it might make sense getting your hands dirty to try and get better performances.