Articles & Books

Triple trip report from ACCU, C++ Russia and C++Now 2018 – Part 1--Jonathan Boccara

Were you there?

Triple trip report from ACCU, C++ Russia and C++Now 2018 – Part 1

by Jonathan Boccara

From the article:

Going to conferences is a great experience, to learn about your domain and meet people that work in it. Going to conferences can give you tools to write better code.

I’ve had the chance to go to (and speak at) three conferences over a month:

  • ACCU in Bristol, UK at the beginning of April,
  • C++ Russia in Saint-Petersburg, Russia in mid April,
  • C++Now in Aspen, US at the beginning of May.

I haven’t seen many people attending all three of them, so I figured I could make a combined trip report, to give you an idea of what they’re like. And more importantly what you would get by attending either one.

And a huge thanks to the company I work for, Murex, for sending me all over the world of C++!

C++ User Group Meetings in June

Lots of User Groups are meeting in June, Meeting C++ has posted an detailed overview:

C++ User Group Meetings in June 2018

by Jens Weller

From the article:

The monthly overview of upcoming C++ User Group meetings. Join a C++ User Group near you, or learn how to start your own!

There are 4 new C++ User Groups: Houston, Prague, Cluj, New York.

 

App-level Developer on std::error Exceptions Proposal for C++. Part II. The Discussion.--"No Bugs" H

Nothing is easy.

App-level Developer on std::error Exceptions Proposal for C++. Part II. The Discussion.

by "No Bugs" Hare

From the article:

For quite a long while, in certain parts of C++ community, there is a substantial resistance to existing C++ exceptions; this leads to an alternative subculture of using error codes instead of exceptions, so there are effectively two barely-compatible C++ worlds: world-using-exceptions, and world-using-error-codes...

Revisting Regular Types -- Titus Winters

An updated discussion on C++ type design, especially the overlap between Regular and reference types.

Revisiting Regular Types

By Titus Winters

From the article:

With 20 years of experience, we know that Regular type design is a good pattern - we should model user-defined types based on the syntax and semantics of built-in types where possible. However, common formulations of Regular type semantics only apply to values, and for performance reasons we commonly pass by reference in C++. In order to use such a reference as if it were its underlying Regular type we need some structural knowledge of the program to guarantee that the type isn’t being concurrently accessed. Using similar structural knowledge, we can treat some non-Regular types as if they were Regular, including reference types which don’t own their data. Under such an analysis, string_view indeed behaves as if it were Regular when applied to common usage (as a parameter). However, span does not, and further it is (currently) impossible to have shallow copy, deep compare, and Regular const semantics in the same type in C++.

This analysis provides us some basis to evaluate non-owning reference parameters types (like string_view and span) in a practical fashion, without discarding Regular design.

Automatic Object Linkage, with Include Graphs -- Thomas Young

For C++ code-bases with multiple targets and shared code elements, static libraries are kind of the default approach, but is there a better way to set this up?

Automatic Object Linkage, with Include Graphs

by Thomas Young

From the article:

In this post I describe an alternative approach to sharing source code elements between multiple build targets.

 

...

We'll need to enforce some constraints on the way the source code is set up, notably with regards to header file organisation, but can then automatically determine what to include in the link operation for each build target, based on a graph of include relationships extracted from the source files.

The resulting dynamic, fine grained, object-file centric approach to code sharing avoids the need for problematic static library decomposition, and the associated 'false dependencies'.