Articles & Books

An Introduction to Reflection in C++--Jackie Kay

What's the status of reflection in C++?

An Introduction to Reflection in C++

by Jackie Kay

From the article:

Stop me if you’ve heard this one before. You are working on a messaging middleware, a game engine, a UI library, or any other large software project that has to deal with an ever-growing, ever-changing number of objects. These objects have many different qualities but can be grouped by their functionality: they can be sent across the network or collided with or rendered.

Because you are a good programmer who believes in the DRY principle, you want to write the “action” code that does the stuff on these objects without repetition, and plug in specific Message types or Renderable types into your generic pipeline at the appropriate places. It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes...

Final Classes--Arne Mertz

Some thoughts about final classes.

Final Classes

by Arne Mertz

From the article:

A few days ago, a colleague asked me if it was wise to make every class a final class. Here is a more sophisticated answer than I could give at that time...

Quick Q: std::move with std::shared_ptr in lambda

Quick A: Lambda captures are const by default, and it is not possible to move a const.

Recently on SO:

std::move with std::shared_ptr in lambda

The captured variable ptr in a lambda is by default const, i.e. the type of ptr is const std::shared_ptr<int>.

std::move cannot move out const objects, so a copy is created instead.

If you really want to move it, the ptr must be allowed to be mutable:

auto lambda = [ptr]() mutable {

Quick Q: Are the experimental features of modern C++ reliable for long-term projects?

Quick A: No

Recently on SO:

Are the experimental features of modern C++ reliable for long-term projects?

Is it guaranteed that all compliant compilers have the same experimental features?
No, experimental features are optional.
Are experimental features prone to big changes that make them unreliable?
Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.

Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).

Post-Conditions on Self-Move--Eric Niebler

An issue we do not think often about:

Post-Conditions on Self-Move

by Eric Niebler

From the article:

TL;DR: In addition to the usual rule about move operations leaving the source object in a valid but unspecified state, we can add an additional guideline (not quite a rule, but follow it anyway):

Self-move assignment should “work” and leave the object in a valid but unspecified state.

Quick Q: Prevent user from derive from incorrect CRTP base

Quick A: Make it impossible to construct a class of the wrong type.

Recently on SO:

Prevent user from derive from incorrect CRTP base

1) make all constructors of Base private (if there are no constructors, add one)

2) declare Derived template parameter as friend of Base

template <class Derived>
class Base
{
private:

  Base(){}; // prevent undesirable inheritance making ctor private
  friend  Derived; // allow inheritance for Derived

public :

  void call ()
  {
      static_cast<Derived *>(this)->call_impl();
  }
};

After this it would be impossible to create any instances of the wrong inherited D2.

Quick Q: Conditionally acquire an std::mutex

Quick A: use a std::unique_lock with std::try_to_lock parameter in the constructor.

Recently on SO:

Conditionally acquire an std::mutex

It is actually unsafe to have a unique_lock accessible from multiple threads at the same time. I'm not familiar with the opencv portion of your question, so this answer is focused on the mutex/lock usage.

static std::mutex s_FAST_GPU_mutex;
{
   // Create a unique lock, attempting to acquire
   std::unique_lock<std::mutex> guard(s_FAST_GPU_mutex, std::try_to_lock);
   if (guard.owns_lock())
   {
       cv::gpu::FAST_GPU(/*params*/)(/*parameters*/);
       guard.unlock(); // Or just let it go out of scope later
   }
   else
   {
       cv::FAST(/*parameters*/);
   }
}

This attempts to acquire the lock, if it succeeds, uses FAST_GPU, and then releases the lock. If the lock was already acquired, then goes down the second branch, invoking FAST

Smelly std::pair and std::tuple--Arne Mertz

Do you use them badly?

Smelly std::pair and std::tuple

by Arne Mertz

From the article:

Depending on their use, std::pair and std::tuple can be code smells. That’s why we should be careful around these two.

Having a code smell is not a no-go, it’s more like a red flag. It’s one of those things that are not a problem themselves but rather a hint that there might be a less obvious problem hidden in the code.

Making things do stuff – Part 1--Glennan Carnie

C++ for embedded too!

Making things do stuff – Part 1

by Glennan Carnie

From the article:

C has long been the language of choice for smaller, microcontroller-based embedded systems; particularly for close-to-the-metal hardware manipulation.

C++ was originally conceived with a bias towards systems programming; performance and efficiency being key design highlights.  Traditionally, many of the advancements in compiler technology, optimisation, etc., had centred around generating code for PC-like platforms (Linux, Windows, etc).  In the last few years C++ compiler support for microcontroller targets has advanced dramatically, to the point where Modern C++ is a increasingly attractive language for embedded systems development...