Articles & Books

Quick Q: Implicit conversion and operator overload

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.

C++ User Group Meetings in March

The monthly overview on upcoming C++ User Group meetings by Meeting C++

C++ USer Group Meetings in March 2019

by Jens Weller

From the article

The monthly overview of upcoming C++ User Group meetings! Lots of groups already announced their meetings, if your group is not in the list, they might announce later.

Want to speak at a User Group? Use the contact form to reach out to several User Groups that you'd be able to visit for a talk!

There are 4 new C++ User Groups...

Overload 149 is now available

ACCU’s Overload journal of February 2019 is out. It contains the following C++ related articles.

Overload 149 is now available

From the journal:

Rip It Up and Start Again.
Some things can be resurrected, others cannot. Frances Buontempo wonders when we need to repent and start over.

5 Big Fat Reasons Why Mutexes Suck Big Time.
Mutable shared state in multithreaded code is often protected by mutexes. Sergey Ignatchenko reminds us that Re-Actors can avoid many of the problems.

A Small Universe.
Writing a programming language is a hot topic. Deák Ferenc shows us how he wrote a compiler for bytecode callable from C++.

QM Bites: Understand Windows Operating-System Identification Preprocessor Macros.
Quality matters and bite sized articles help. Matthew Wilson returns with a QM Bites.

A Thorough Introduction to Distributed Systems.
What is a distributed system, and why is it so complicated? Stanislav Kozlovski explains.

Don’t Use std::endl.
How do you add a new line in C++? Chris Sharpe suggests std::endl is a tiny utility that’s more trouble than it’s worth.

Cpp On Sea 2019 Trip Report--Arne Mertz

Were you there?

Cpp On Sea 2019 Trip Report

by Arne Mertz

From the article:

From February 3rd through February 6th I have been in Folkestone, UK, to visit the first C++ On Sea conference.

There must be something in the water on that island that enables them to organize fantastic conferences like ACCUConf and, since this year, C++ On Sea.
C++ On Sea is definitely the best conference I have ever been to, and here’s a little glimpse why I think so...

2 Lines Of Code and 3 C++17 Features - The overload Pattern--Bartlomiej Filipek

Proof that you can do more!

2 Lines Of Code and 3 C++17 Features - The overload Pattern

by Bartlomiej Filipek

From the article:

While I was doing research for my book and blog posts about C++17 several times I stumbled upon this pattern for visitation of std::variant:

template<class... Ts> struct overload : Ts... { using Ts::operator()...; };
template<class... Ts> overload(Ts...) -> overload<Ts...>;

std::variant<int, float> intFloat { 0.0f };
std::visit(overload(
    [](const int& i) { ... },
    [](const float& f) { ... },
  ),
  intFloat;
);

With the above pattern, you can provide separate lambdas “in-place” for visitation.

It’s just two lines of compact C++ code, but it packs a few interesting concepts.

Let’s see how this thing works and go through the three new C++17 features that enable this one by one.

Why You Should Use std::for_each over Range-based For Loops--Jon Kalb

What do you think?

Why You Should Use std::for_each over Range-based For Loops

by Jon Kalb

From the article:

I’d like start by thanking Jonathan for creating and maintaining the Fluent{C++} blog, for the conversations that it spawns, and for letting me contribute with this guest post. Jonathan has invited me to add my thoughts on his previous posting, Is std::for_each obsolete?