max max - 2 months ago 20
C++ Question

Why is implicit conversion from const to non-const allowed?

Why does C++ allow the following code to compile?

std::unordered_map<std::string, int> m;
// ...
for (const std::pair<std::string, int>& p: m)
{
// ...
}


According to Scott Meyers' Effective Modern C++ (p. 40-41):


[...] the key part of a
std::unordered_map
is
const
, so the type of
std::pair
in the hash table (which is what a
std::unordered_map
is) isn’t
std::pair<std::string, int>
, it's
std::pair <const std::string, int>
. But that's not the type declared for the variable
p
in the loop above. As a result, compilers will strive to find a way to convert
std::pair<const std::string, int>
objects (i.e., what’s in the hash table) to
std::pair<std::string, int>
objects (the declared type for
p
). They’ll succeed by creating a temporary object of the type that
p
wants to bind to by copying each object in
m
, then binding the reference p to that temporary object. At the end of each loop iteration, the temporary object will be destroyed. If you wrote this loop, you'd likely be surprised by this behavior, because you'd almost certainly intend to simply bind the reference
p
to each element in
m
.


What is the benefit of allowing this implicit conversion? Is there some common use case where the developer would expect / prefer this implicit conversion (rather than getting a compiler error)?

Answer Source

Let's "convert" your ranged loop to what the compiler "translate" it. It would look something like this:

auto&& __range = m; 
for (auto __begin = std::begin(m), __end = std::end(m); __begin != __end; ++__begin) { 
    const std::pair<std::string, int>& p = *__begin;
    //loop_statement 
}

Which basically boils down your question to why the following code is allowed:

std::pair<std::string, int> p = std::pair<const std::string, int>{};

Note that I dropped the const& part of p, because it isn't relevant. The conversion is the same, the only difference is that the temporary is bound to a reference instead of being copied.

This is allowed because std::pair has a constructor that enables this conversion.

template< class U1, class U2 >
pair( const pair<U1, U2>& p );

In your case, U1 is deduced as const std::string and U2 as int. It doesn't actually matter what cv qualifiers U1 and U2 have, because p's elements get copied.

The benefits are the same as to why this is allowed:

const int zero{};
int zero2 = zero;

For example, consider the following non-realistic example:

struct {
    std::pair<int, int> pos;
} player;

std::pair<const int, const int> treasure{1, 2}; // position of treasure
player.pos = treasure; // ok

Now what if, as you say, this conversion were for some reason not allowed. What would the programmer have to do?

player.pos.first = treasure.first;
player.pos.second = treasure.second;

If this would also be disallowed, then the case with the zeroes above would also not be allowed, which doesn't really make sense, because you are copying zero, so it shouldn't matter if you can modify it or not, because that is a totally different operation.

If this is allowed, then why would player.pos = treasure; be disallowed, because the only thing that it does is copying? Like above, it shouldn't matter whether you can change the elements of treasure, because you are only copying them.

This is also why you should use auto&& or const auto& for ranged loops (and maybe even in general?) because it can avoid a copy if you're not careful.