Articles & Books

C++17 in details: Code Simplification—Bartlomiej Filipek

The series continue.

C++17 in details: Code Simplification

by Bartlomiej Filipek

From the article:

You might say that most of the new language features (not to mention The Standard Library improvements) are there to write simpler/cleaner code. The “C++17 in details” series reviews most of the bigger things, still for today, I tried to pick a few features that out of the box make your code more compact.

  • Structured bindings/Decomposition declarations
  • Init-statement for if/switch
  • Inline variables
  • constexpr if (again!)
  • a few other mentions

Quick Q: How to require an exact function signature in the detection idiom?

Quick A: Use is_detected

Recently on SO:

How to require an exact function signature in the detection idiom?

With C++17 is_detected, you may do

template <typename T, typename Ret, typename Index>
using subscript_t = std::integral_constant<Ret (T::*) (Index), & T::operator[]>;

template <typename T, typename Ret, typename Index>
using has_subscript = is_detected<subscript_t, T, Ret, Index>;

static_assert(has_subscript<std::vector<int>, int&, std::size_t>::value, "!");
static_assert(!has_subscript<std::vector<int>, int&, int>::value, "!");

Metaclasses: Thoughts on generative C++—Herb Sutter

The ACCU 2017 keynote video is now online, with context and updates from this month's standards meeting:

Metaclasses: Thoughts on generative C++

by Herb Sutter

From the article:

I’ve been working on an experimental new C++ language feature tentatively called “metaclasses” that aims to make C++ programming both more powerful and simpler. You can find out about it here...

C++17 attributes - maybe_unused, fallthrough and nodiscard—Simon Brand

Do you know these new attributes?

C++17 attributes - maybe_unused, fallthrough and nodiscard

by Simon Brand

From the article:

C++17 adds three new attributes for programmers to better express their intent to the compiler and readers of the code: maybe_unused, fallthrough, and nodiscard. This is a quick post to outline what they do and why they are useful.

Quick Q: Why is the count of weak_ptr tracked also?

Quick A: To be able to know when to delete the control block.

Recently on SO:

Why shared_ptr's reference counting object needs to keep track of the number of weak_ptrs pointing to the object too?

std::weak_ptr refers to the control block to know if the object still exists and if so, to provide a std::shared_ptr to it when needed. For that reason, the control block must exist as long as either a std::weak_ptr or a std::shared_ptr exists. You need to track the number of instances of std::weak_ptr to know when the last one is destroyed, just like for std::shared_ptr.

Yielding Generators—Kirit Sælensminde

The series continue!

Yielding Generators

by Kirit Sælensminde

From the article:

We've seen how the promise_type together with the coroutine return type handles the interactions between the caller and the coroutine itself.

Our target is to be able to do something pretty simple:

generator count() {
    std::cout << "Going to yield 1" << std::endl;
    co_yield 1;
    std::cout << "Going to yield 2" << std::endl;
    co_yield 2;
    std::cout << "Going to yield 3" << std::endl;
    co_yield 3;
    std::cout << "count() is done" << std::endl;
}

Quick Q: How to (and who can) implement the standard library features defined by the C++ committee?

Quick A: Everyone by reading and applying the C++ standard.

Recently on SO:

How to (and who can) implement the standard library features defined by the C++ committee?

The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.

Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.

You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).

I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.

If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.

Your own error code—Andrzej Krzemieński

The stl can help you!

Your own error code

by Andrzej Krzemieński

From the article:

I was recently implementing the “classification of error conditions” in my application offered by the functionality behind std::error_code. In this post I want to share some of my experience and insight.

Zero-allocation continuations in C++17 — Vittorio Romeo

This series of articles show the design and implementation of future-like asynchronous computation chains that do not require any dynamic memory allocation or type erasure. 

by Vittorio Romero

From the article:

I'd like to show an alternative design [for futures] that doesn't require any allocation whatsoever and still enables users to build up asynchronous computation chains using facilities such as `when_all` and `.then`. [...] The idea behind it is to encode the entire computation chain into a single object with a huge type.