Keynotes at Meeting C++ 2017

With the conference just a few weeks away, an update on the 3 awesome keynotes of this years Meeting C++:

Keynotes at Meeting C++ 2017

by Jens Weller

From the article:

Are you excited for Meeting C++ 2017?!? I quickly wanted to give an update on the 3 keynotes at the conference this year! Each day will feature one keynote, where the first two are in the morning, while the Closing Keynote is kind of the last thing to happen before the closing message. Also, all 3 keynote speakers have now (finally) their speaker profile.

Quick Q: What are template deduction guides in C++17?

Quick A: A solution for automatic template resolution on constructors.

Recently on SO:

What are template deduction guides in C++17?

Template deduction guides are patterns associated with a template class that tell the compiler how to translate a set of parameter (and their types) into template arguments.

The simplest example is that of std::vector and its constructor that takes an iterator pair.

template<typename Iterator>
void func(Iterator first, Iterator last)
  vector v(first, last);

The compiler needs to figure out what vector<T>'s T type will be. We know what the answer is; T should be typename std::iterator_traits<Iterator>::value_type. But how do we tell the compiler without having to type vector<typename std::iterator_traits<Iterator>::value_type>?

You use a deduction guide:

template<typename Iterator> vector(Iterator b, Iterator e) -> vector<typename std::iterator_traits<Iterator>::value_type>;

This tells the compiler that, when you call a vector constructor matching that pattern, it will deduce the vector specialization using the code on the right of ->.

You need guides when the deduction of the type from the arguments is not based on the type of one of those arguments. Initializing a vector from an initializer_list explicitly uses the vector's T, so it doesn't need a guide.

The left side doesn't necessarily specify a constructor. The way it works is that, if you use template constructor deduction on a type, it matches the arguments you pass against all deduction guides (actual constructors provide implicit guides). If there is a match, it uses that to determine which template arguments to provide to the type. But overload resolution to determine which constructor to call happens after that.

This also means that you can use guides with aggregates and aggregate initialization:

template<typename T>
struct Thingy
  T t;

Thingy(const char *) -> Thingy<std::string>;

Thingy thing{"A String"}; //thing.t is a `std::string`.

So deduction guides are only used to figure out the type being initialized. The actual process of initialization works exactly as it did before, once that determination has been made.

Quick Q: Array Initialisation Compile Time - Constexpr Sequence

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


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);

CppCon 2016: The Exception Situation—Patrice Roy

Have you registered for CppCon 2017 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2016 for you to enjoy. Here is today’s feature:

The Exception Situation

by Patrice Roy

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Exceptions have been a part of C++ for a long time now, and they are not going away. They allow programmers to concentrate on the meaningful parts of their code and treat the things that happen infrequently as… well, exceptional situations, to be dealt with when and where the context makes it reasonable or useful.

On the other hand, some significant parts of the C++ programming community either dislike this mechanism or outright reject it, for a number of reasons. Work in SG14 has raised performance issues in some cases; there are those who dislike the additional execution paths introduced in programs that rely on exceptions; some programmers raised issues with respect to exceptions and tooling, integration with older codebases, writing robust generic code, etc.

This talk will be neither for not against exceptions. It will present a perspective on cases where they make sense, cases where they are less appropriate, alternative disappointment handling techniques presented along with client code in order to show how the various approaches influence the way code is written. Performance measurements will be given along the way. Some creative uses of exceptions will also be presented in order to spark ideas and discussions in the room.

Quick Q: Make C++ fail compilation on specific instantiation of template function

Quick Q: Delete its constructor

Recently on SO:

Make C++ fail compilation on specific instantiation of template function

Since foo is a complete specialization, it will always get compiled, and the static assert will always get called.

However, there’s an easier way:

template <>
Bar foo<Bar>(Bar val) = delete;

This will say that this specific version is deleted, and cannot be called.

Ranges, Coroutines, and React: Early Musings on the Future of Async in C++—Eric Niebler

Eric Niebler shares his thoughts about the interaction of ranges and co-routines in his recent blog post.

Ranges, Coroutines, and React: Early Musings on the Future of Async in C++

by Eric Niebler

From the article:

Another way to look at this is that synchronous ranges are an example of a pull-based interface: the user extracts elements from the range and processes them one at a time. Asynchronous ranges, on the other hand, represent more of a push-based model: things happen when data shows up, whenever that may be. This is akin to the reactive style of programming.

By using ranges and coroutines together, we unify push and pull based idioms into a consistent, functional style of programming. And that’s going to be important, I think.