Home » Blog » Categories »

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.

C++Now 2019 Attendee Video

By foonathan | Mar 7, 2019 12:49 PM | Tags: None

"There's really not a conference like this one"

Register now for C++Now 2019 at cppnow.org!

C++Now 2019 Attendee Video

by C++ Now attendees

About the video

This video was created by Vittorio Romeo, Lisa Lippincott, Zach Laine, Odin Holmes, Phil Nash, Anastasia Kazakova, Jens Weller, and more

 

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!

Formatting user-defined types with {fmt} library--Wojtek Gumuła

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

The future.

Formatting user-defined types with {fmt} library

by Wojtek Gumuła

From the article:

C++ has two standardized ways of printing formatted text out already: printf-family functions inherited from C and I/O streams abstraction built on operator<<. Streams are considered more modern, providing type-safety and extensibility functionalities. However, printf have some notable advantages, too — at the cost of lost type-safety, user can use an interface that looks familiar to almost all developers, allowing for some ways of localization and more readable syntax. And then, there is {fmt} — yet another text formatting library, inspired by design already available in languages like Python and Rust...

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.