Tutorial: Emulating strong/opaque typedefs in C++—Jonathan Müller

Who would like this feature?

Tutorial: Emulating strong/opaque typedefs in C++

by Jonathan Müller

From the article:

Last week, I’ve released my type_safe library. I described it’s features in the corresponding blog post but because the blog post got rather long, I couldn’t cover one feature: strong typedefs.

Strong or opaque typedefs are a very powerful feature if you want to prevent errors with the type system - and as I’ve been advocating for, you want that. Unlike “normal” typedefs, they are a true type definition: they create a new type and allow stuff like overloading on them and/or prevent implicit conversions.

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...

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} {}

    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} {}

    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...

Universal vs Forwarding References in C++—Petr Zemek

Do you know the difference?

Universal vs Forwarding References in C++

by Petr Zemek

From the article:

When talking about T&& in C++, you may have heard about universal references and forwarding references. This may get you wonder. Why there are two names for an apparently same concept? Is there any difference between them? Which one should I use? Lets find out...

Quick Q: std::ignore for ignoring unused variable

Quick A: While in theory possible, it is not the intended usage and other solutions exist.

Recently on SO:

std::ignore for ignoring unused variable

std::ignore may work but it is intended to be used for tuples. So you need to include the tuple header and who knows what operations are done for the assignment. This also may break in another c++ version because it was never documented to be used that way.

A better way for this is the C++17 attribute [[maybe_unused]]

void func([[maybe_unused]] int i)

It places the declaration right at the variable declaration, so you don't have to declare it in an extra line/statement.

The same can be used for local (and local-static) variables

[[maybe_unused]] static int a = something();

And also for many more:

Appears in the declaration of a class, a typedef­, a variable, a non­static data member, a function, an enumeration, or an enumerator. If the compiler issues warnings on unused entities, that warning is suppressed for any entity declared maybe_unused.


As for the people concerned that you can still use the variables after you declare them unused:

Yes, this is possible but (at least with clang) you will get warnings in case you use maybe_unused declared variables.