Articles & Books

C++ User Group Meetings in February

The monthly overview on upcoming C++ User Group Meetings:

C++ User Group meetings in February

by Jens Weller

From the article:

The monthly overview on upcoming C++ User Group meetings. For February there are already 33 User Group meetings planned. Also in this month are emBO++ and C++ Russia!

There are 4 new C++ User Groups: Nashua, NH, Vienna (Qt), Austin (Mentoring & Study Group), Montréal.

Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types -- Marc Mutz

Marc Mutz wrote in his recent article about the properties of default constructed object as required by Elements of Programming.

Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types

by Marc Mutz

From the article:

In this article, I will take a look at one of the fundamental concepts introduced in Alex Stepanov and Paul McJones’ seminal book “Elements of Programming” (EoP for short) — that of a (Semi-)Regular Type and Partially-Formed State.

Using these, I shall try to derive rules for C++ implementations of what are commonly called “value types”, focusing on the bare essentials, as I feel they have not been addressed in sufficient depth up to now: Special Member Functions.

zero-overhead C++17 currying & partial application -- Vittorio Romeo

This article briefly explains the concepts of "currying" and "partial application", then covers the design and C++17 implementation of a generic zero-overheader constexpr `curry` function.

zero-overhead C++17 currying & partial application

by Vittorio Romeo

From the article:

[...] many features introduced in the latest C++ standards allow functional patterns to thrive in your codebase, [...] like currying and partial application. [...] In this article we're going to:

* Introduce and briefly explain the two aforementioned concepts.

* Write a generic constexpr zero-overhead `curry` function in C++17.

* Analyze the generated assembly of the implementation to prove the lack of overhead.

[...]

Given a generic function object `f`, invoking `curry(f)` will return a curried/partially-applicable version of `f`. If `f` is constexpr-friendly, the returned one will be as well. `curry` should not introduce any overhead compared to hand-written currying/partial application.

Istream Idiosyncrasies -- Adi Shavit

Idiosyncrasies with istreams.

Istream Idiosyncrasies

by Adi Shavit

From the article:

A lot has been written and the vice and virtues of the C++ iostreams library.
While working on Argh, my little C++11 argument parsing library, I ran across some somewhat surprising idiosyncrasies and a few interesting lessons.

The Future of Generic Programming -- How to design good concepts and use them well -- Stroustrup

This new paper by Bjarne Stroustrup has been brewing over the holidays, and is now ready for release as a prepublication draft:

Concepts: The Future of Generic Programming
or, How to design good concepts and use them well

by Bjarne Stroustrup

From the draft paper:

Conclusions

Concepts complete C++ templates as originally envisioned. I don’t see them as an extension but as a completion.

Concepts are quite simple to use and define. They are surprisingly helpful in improving the quality of generic code, but their principles – and not just their language-technical details – need to be understood for effective use. In that, concepts are similar to other fundamental constructs, such as functions. Compared to unconstrained templates, there are no run-time overheads incurred by using concepts.

Concepts are carefully designed to fit into C++ and to follow C++’s design principles:

  • Provide good interfaces
  • Look for semantic coherence
  • Don’t force the user to do what a machine does better
  • Keep simple things simple
  • Zero-overhead

Don’t confuse familiarity and simplicity. Don’t confuse verbosity with “easy to understand.” Try concepts! They will dramatically improve your generic programming and make the current workarounds (e.g., traits classes) and low-level techniques (e.g., enable_if – based overloading) feel like error-prone and tedious assembly programming.

Const, Move and RVO--Bartlomiej Filipek

const does not prevent (N)RVO, youhou.

Const, Move and RVO

by Bartlomiej Filipek

From the article:

C++ is a surprising language. Sometimes simple things are not that simple in practice. Last time I argued that in function bodies const should be used most of the time. But two cases were missed: when moving and when returning a value.

Does const influence move and RVO?