Home » Blog » Categories » Articles & Books

Articles & Books

Understanding C++ Modules: Part 1: Hello Modules, and Module Units--Colby Pike

By Adrien Hamelin | Mar 12, 2019 12:04 PM | Tags: experimental advanced

Complex, but useful!

Understanding C++ Modules: Part 1: Hello Modules, and Module Units

by Colby Pike

From the article:

My previous posts on modules have received a lot of attention. I’m happy that I’ve been able to kick-start a lot of conversation, but I’ve also seen that a large part of the community is still unclear on what modules actually are.

There is a lot of ground to cover. I can’t do it all in one sitting, and I doubt you’d want to read the entire thing in one go. I’ll be breaking this up, starting at the most high-level aspects and drilling down over time. I intend these posts will clarify and discuss what modules are, what they can do, and what they are intended to do, what they cannot do, and how they are used...

Lambdas: From C++11 to C++20, Part 2--Bartlomiej Filipek

By Adrien Hamelin | Mar 12, 2019 11:54 AM | Tags: experimental c++17

The series continues!

Lambdas: From C++11 to C++20, Part 2

by Bartlomiej Filipek

From the article:

In the first part of the series we looked at lambdas from the perspective of C++03, C++11 and C++14. In that article, I described the motivation behind this powerful C++ feature, basic usage, syntax and improvements in each of the language standards. I also mentioned several corner cases.

Now it’s time to move into C++17 and look a bit into the future (very near future!): C++20...

STL Algorithms on Tuples--Jonathan Boccara

By Adrien Hamelin | Mar 12, 2019 11:46 AM | Tags: stl c++17

Do you need them?

STL Algorithms on Tuples

by Jonathan Boccara

From the article:

When you manipulate a collection of objects in C++–which is quite a common thing to do when programming in C++–STL algorithms are your loyal companions to perform operations with expressive code.

But the STL algorithms, shipped in the standard library with C++, only apply to collections that are filled at runtime, during the execution of a program (or in C++20, during the execution of constepxr code during compilation). This include the ubiquitous std::vector and std::map.

But STL algorithms don’t operate on std::tuples.

However, it could be useful to iterate over the elements of a tuple, at runtime, and perform transformations or extract information, like STL algorithms do. We will see in detail a situation where this is useful with the demux output iterator, in a future post.

Can we design algorithms that are do what STL algorithms do, but on the contents of std::tuples instead of std::vectors and std::maps?

It turns out we can.

Trip report: February 2019 ISO C++ committee meeting, Kona, Hawai’i--Timur Doumler

By Adrien Hamelin | Mar 5, 2019 01:21 PM | Tags: community

Another report.

Trip report: February 2019 ISO C++ committee meeting, Kona, Hawai’i

by Timur Doumler

From the article:

What better way to start my new blog than to publish a trip report from the most recent C++ committee meeting on the wonderful Big Island of Hawai’i?

If you are looking for an incredibly detailed report of everything that happened, please instead head to this report by Bryce and others, and also see Herb Sutter’s and cor3ntin’s reports. I won’t try to provide this breadth of coverage, and instead focus on a few areas that are particularly relevant for me and the community that I am proxying here:

  • Making C++ simpler, more uniform, and easier to teach;
  • Providing developers with better tools;
  • Improving support for low-latency and real-time(-ish) programming,
  • 2D Graphics, Audio, and other forms of I/O and human-machine interaction.

That being said, let’s start with the big news: we voted both Coroutines and Modules into C++20!

Quick Q: Implicit conversion and operator overload

By Adrien Hamelin | Mar 4, 2019 01:08 PM | Tags: intermediate

Quick A: it tries to convert to int.

Recently on SO:

Implicit conversion and operator overload

In comparing the conversions needed by different overloaded functions, a "promotion" is considered a better conversion sequence than a standard "conversion". Every arithmetic type can promote to at most one other type. (Promotions are also used when passing an argument to a C-style variadic function like printf. The unary + operator can be used to force a promotion of an arithmetic expression, like +n.)

For integer types which are not character types or bool, the promoted type is:

  • If int can represent all the values of the original type, then int;
  • Otherwise, if unsigned int can represent all the values of the original type, then unsigned int;
  • Otherwise, the original type itself (promotion does nothing)

In your example, when comparing the overloaded functions, an "exact match" would be best, but there is no function taking exactly int8_t (or int8_t& or const int8_t&). The promoted type of uint8_t is int, since it's required to support a range much larger than 0-255. And apparently on your system, int32_t is an alias for int, so the function void f(int32_t); requires only a promotion on the argument. The other functions are all viable, but require an integer conversion on the argument. So void f(int32_t); is considered the best overload.

So the technical answer to the question is that it is implementation specific, but only because of the relationship between int and the <cstdint> types, not because of the overload resolution rules.