Articles & Books

Overload 135 is now available

ACCU’s Overload journal of October 2016 is out. It contains the following C++ related articles.

Overload 135 is now available

From the journal:

Determinism: Requirements vs Features
A program can easily be non-deterministic. Sergey Ignatchenko considers how to define determinism. by Sergey Ignatchenko

Eight Rooty Pieces
Finding a square root is a common interview question. Patrick Martin demonstrates eight different ways to find a root. by Patrick Martin

Polymorphic Comparisons
Polymorphic comparisons require much boilerplate. Robert Mill and Jonathan Coe introduce a template utility for such comparisons. by Robert Mill and Jonathan Coe

C++ Synchronous Continuation Passing Style
Direct and continuation passing styles differ. Nick Weatherhead explains a continuation passing style for synchronous data flow. by Nick Weatherhead

Attacking Licensing Problems with C++
Software licenses are often crackable. Deák Ferenc presents a technique for tackling this problem. by Deák Ferenc

camomilla: C++ error simplification script - - Vittorio Romeo

Article covering "camomilla", a Python script designed to post-process heavily-template-based C++ errors in order to make them easier to read.

camomilla: C++ error simplification script

by Vittorio Romeo

From the article:

camomilla uses simple text transformations to make gcc and clang errors smaller and easier to read. [...] The main text transformation used by camomilla to prevent full expansion of templates is "template typename collapsing", which hides nested typenames up to a user-specified depth. [...] The two other current transformations offered by camomilla are simple regex replacements that can act on namespaces or generic symbols. They can be defined in .json configuration files (which can recursively include each other!) [...] camomilla helps with [continuously transforming the same error] by automatically caching the last processed original error, so that the user can play around with different transformations and options.

DLib 19.2 released

Today a new version of DLib is available:

DLib 19.2 released

Release notes

by Davis King

From the article:

... So the obvious thing to do was to add an implementation of MMOD with the HOG feature extraction replaced with a convolutional neural network.  The new version of dlib, v19.2, contains just such a thing.  On this page you can see a short tutorial showing how to train a convolutional neural network using the MMOD loss function.  It uses dlib's new deep learning API to train the detector end-to-end on the very same 4 image dataset used in the HOG version of the example program.  Happily, and very much to the surprise of myself and my colleagues, it learns a working face detector from this tiny dataset.

Optimizing return values--Marco Foco

Marco Foco shows different solutions and tradeoffs to a dangling reference problem:

Optimizing return values

    by Marco Foco

From the article:

As you can see, class C contains a function get() which returns a reference to its internal state. In normal code, we must take care not to use this reference after our class has been destroyed...

Quick Q: Is the 'override' keyword just a check for a overriden virtual method?

Quick A: Yes.

Recently on SO:

Is the 'override' keyword just a check for a overriden virtual method?

That's indeed the idea. The point is that you are explicit about what you mean, so that an otherwise silent error can be diagnosed:

struct Base
{
    virtual int foo() const;
};

struct Derived : Base
{
    virtual int foo()   // whoops!
    {
       // ...
    }
};

The above code compiles, but is not what you may have meant (note the missing const). If you said instead, virtual int foo() override, then you would get a compiler error that your function is not in fact overriding anything.

CppCon 2016 Trip Report -- Vittorio Romeo

Brief trip report covering thoughts and "lessons learned" from the author's favorite talks and his own sessions.

trip report - CppCon 2016

    By Vittorio Romeo

From the article:

CppCon 2016 ended yesterday - I had the pleasure of attending and presenting at this amazing conference again this year.

I'm really grateful to Jon Kalb, Bryce Lelbach, the conference staff, the speakers, my company and everyone else involved for making this possible.

In the same vein as my C++Now 2016 trip report, I wanted to share my thoughts regarding the talks I liked the most and regarding my sessions.

Opt-in header-only libraries -- Vittorio Romeo

Analysis of a library development technique that allows users to decide whether or not to consume the library as "header-only".

opt-in header-only libraries

    by Vittorio Romeo

From the article:

Libraries can be designed and implemented in order to allow users to choose between header-only usage, static linking or dynamic linking. [...] The main idea is to conditionally include .cpp files depending on a preprocessor macro, which can be defined during compilation. Functions also have to be conditionally decorated with the inline specifier.

C++ in Competitive Programming: compromises--Marco Arena

In this installment I'll explain what I consider the essence of Competitive Programming:

C++ in Competitive Programming: compromises

by Marco Arena

From the article:

Crafting software is about balancing competing trade-offs. It’s impossible to optimize every factor of a system, as speed, usability, accuracy, etc at the same time. Moreover, solutions of today impact decisions and solutions of tomorrow. On the other hand, in Competitive Programming, the best solution is one that just makes each test-case pass...

The Case for Optional References--Tristan Brindle

And why not simply use a pointer?

The Case for Optional References

by Tristan Brindle

From the article:

I have a confession to make. Whenever I’ve come across code that looks like this:

struct example {
    example() = default;

    example(std::string& s) : str_{s} {}

private:
    boost::optional<std::string&> str_{};
};

there is a little voice inside my head that whispers “why didn’t you just use a pointer?”. Like so, for instance:

struct example {
    example() = default;

    example(std::string& s) : str_{&s} {}

private:
    std::string* str_ = nullptr;
};

This is equivalent to the first example, except that it’s slightly less typing, it doesn’t have any dependencies, and feels in some sense “cleaner”. I personally have always preferred it.

Except, I was wrong. After attending Bjarne Stroustrup’s keynote and this excellent talk at Cppcon this morning, I’m persuaded that optional references are a good thing. In this post I hope to be able to convince you of the same...