Home » Blog » Categories » Articles & Books

Articles & Books

Detection Idiom - A Stopgap for Concepts--Simon Brand

By Adrien Hamelin | Sep 20, 2017 12:30 PM | Tags: c++14 advanced

Concepts are not yet here, but there are solutions.

Detection Idiom - A Stopgap for Concepts

by Simon Brand

From the article:

Concepts is a proposed C++ feature which allows succinct, expressive, and powerful constraining of templates. They have been threatening to get in to C++ for a long time now, with the first proposal being rejected for C++11. They were finally merged in to C++20 a few months ago, which means we need to hold on for another few years before they’re in the official standard rather than a Technical Specification. In the mean time, there have been various attempts to implement parts of concepts as a library so that we can have access to some of the power of Concepts without waiting for the new standard. The detection idiom – designed by Walter Brown and part of the Library Fundamentals 2 Technical Specification – is one such solution. This post will outline the utility of it, and show the techniques which underlie its implementation.

Automatic two-phase init -- Krzysztof Ostrowski

By fj | Sep 14, 2017 07:33 AM | Tags: c++14 advanced

Deferred initialisation for classes that inherit constructors, or Automatic two-phase init.

Deferred initialisation for classes that inherit constructors

by Krzysztof Ostrowski

From the article:

Constructor inheritance through using-declaration is a powerful technique that can be easily used to introduce pre-defined behaviour to custom types. As an example, consider a generic visitor design pattern implementation that is parametrised by the names of visitable types, and an unique tag that identifies given visitor template instance. Such an instance can be "mixed-in" into a custom type D by simply deriving from it... and inheriting its constructors to make it behave as it would be a Visitor template instance itself:

struct D
  : Visitor<
        A         // the tag
      , X, Y, Z   // "list" of visitable types
      >
{
    using Visitor::Visitor;
};
What if there is a need to run an "additional" initialisation code as it would be run in the D constructor if one were there? Bjarne Stroustrup suggests member-initializers that do half of a work we would like to do here. While direct member initialisation sets required initial values for all the members (except bit field members), it does not offer a direct way to execute custom code that makes use of those members, the custom code that typically resides in the constructor's body.
This article presents a solution that enables injection of a custom code to be executed once all the non-static members are initialised.

The main() Course -- Adi Shavit

By Adi | Sep 4, 2017 01:05 PM | Tags: basics

A fanciful little post about li’l old main().

The main() Course

by Adi Shavit

From the article:

The function main() is a normal program’s entry point.

The shortest conforming C++ executable program is: int main(){}

Quick Q: Array Initialisation Compile Time - Constexpr Sequence

By Adrien Hamelin | Aug 30, 2017 12:45 PM | Tags: intermediate c++11

Quick A: Use integer_sequence with a helper function.

Recently on SO:

Array Initialisation Compile Time - Constexpr Sequence

1) How to implement that kind of integer_sequence?

template <std::size_t... Is>
constexpr auto make_sequence_impl(std::index_sequence<Is...>)
{
    return std::index_sequence<generate_ith_number(Is)...>{};
}

template <std::size_t N>
constexpr auto make_sequence()
{
    return make_sequence_impl(std::make_index_sequence<N>{});
}

2) Is it possible to build an std::array from that integer_sequence at compile time?

template <std::size_t... Is>
constexpr auto make_array_from_sequence_impl(std::index_sequence<Is...>)
{
    return std::array<std::size_t, sizeof...(Is)>{Is...};
}

template <typename Seq>
constexpr auto make_array_from_sequence(Seq)
{
    return make_array_from_sequence_impl(Seq{});
}

Usage:

int main()
{
    constexpr auto arr = make_array_from_sequence(make_sequence<6>());
    static_assert(arr[0] == 0);
    static_assert(arr[1] == 1);
    static_assert(arr[2] == 2);
    static_assert(arr[3] == 4);
    static_assert(arr[4] == 5);
    static_assert(arr[5] == 7);
}

Quick Q: vector of vector does not convert brace encloser list

By Adrien Hamelin | Aug 30, 2017 12:34 PM | Tags: None

Quick A: The constructor needs an extra {} pair.

Recently on SO:

vector does not convert brace encloser list

You have two options:

  1. add a constructor taking std::initializer_list<std::initializer_list<T>>
  2. eclose the init expression with another set of {} i.e.
Matrix<double> a{{

    { 17,    24,    1},

    { 23,    5,     7 },

    {  4,     6,    13 }

}};

Ok, I'll try a little explanation of what is going on here:

If there is no constructor taking a std::initializer_list then the outermost {} are always opening and closing the constructor call if you will, and not part of what you actually pass to the constructor.

Matrix<double> a{ {1, 2}, {3, 4} };
                ^ ^~~~~~~~~~~~~~ ^
                |  2 parameters  |
                |                |
                |                |
            opening            closing

As you can see this is taken as a constructor with 2 parameters, in this case 2 initializer_lists.

This is why you need another set of {}:

Matrix<double> a{ {{1, 2}, {3, 4}} };
                ^ ^~~~~~~~~~~~~~~~ ^
                |  1 parameter     |
                |                  |
                |                  |
            opening            closing

In order for the outermost {} to be considered an initializer_list then the constructor needs to have an overload taking a initializer_list. That is what is happening in the std::vector case.

Top 20 C++ multithreading mistakes and how to avoid them--Deb Haldar

By Adrien Hamelin | Aug 28, 2017 01:09 PM | Tags: efficiency c++11

You use threads? You should know this.

Top 20 C++ multithreading mistakes and how to avoid them

by Deb Haldar

From the article:

Threading is one of the most complicated things to get right in programming, especially in C++. I've made a number of mistakes myself over the years. Most of these mistakes were  luckily caught in code review and testing ; however, some arcane ones did slip through and make it into production code and we had to patch live systems, which is always expensive.

In this article, I've tried to catalog all the mistakes I know of, with potential solutions. If you know any more pitfalls, or have alternative suggestions for some of the mistakes – please leave a comment below and I'll factor them into the article.

C++17 in detail: Parallel Algorithms -- Bartlomiej Filipek

By bfilipek | Aug 23, 2017 10:23 AM | Tags: performance c++17

Let’s see how C++17 can make writing parallel code a bit easier.

C++17 in details: Parallel Algorithms

by Bartlomiej Filipek

From the article:

With C++17 we get a lot of algorithms that can be executed in a parallel/vectorized way. That’s amazing, as it’s a solid abstraction layer. With this making, apps is much easier. A similar thing could be achieved possibly with C++11/14 or third-party APIs, but now it’s all in the standard.