Re: Those implicit conversions ...

[Paavo Helde]

r...@zedat.fu-berlin.de (Stefan Ram) wrote in news:conversions-
2015060...@ram.dialup.fu-berlin.de:

>
> . Do you remember other simple or famous cases of
> implicit conversions of the standard library?

With the standard library my favorite goes to double-to-int conversion with
::abs(int) if one has somehow included the header for C abs(int) and
forgetten to include the right headers to have the ::abs(double) overload.
As C++ standard library headers may include each other in unpredictable
ways, this situation can occur just by a c++ version upgrade.

But I think the most unfortunate automatic conversion is converting 0 to a
pointer. Not standard library, but this makes it even worse.

Cheers
Paavo

[Luca Risolia]

Il 07/06/2015 08:22, Stefan Ram ha scritto:
> I am looking for »(in)famous« examples of implicit conversions
> with user-defined types of the C++ standard library.

> 2nd) a stream can be implicitly converted to a bool.

It's

explicit operator bool() const;

since C++11.

bool a = std::cout; // ERROR
bool a{std::cout}; // OK

[Öö Tiib]

On Sunday, 7 June 2015 09:22:45 UTC+3, Stefan Ram wrote:
> You know, all those implicit conversions annoy you
> when they kick in unexpectedly and you only wish that
> that conversion had been defined »explicit«, but ...
>
> then, when you are searching for implicit conversions
> for example purposes, suddenly none comes to your memory?

>
> I am looking for »(in)famous« examples of implicit conversions
> with user-defined types of the C++ standard library.
>

> So far, I remember that
>
> 1st) a char* can be implicitly converted to a ::std::string
>
> and

>
> 2nd) a stream can be implicitly converted to a bool.
>

> It also seems to be possible to implicitly convert a
> double to complex<double> via
>
> constexpr complex(const T& re = T(), const T& im = T());

>
> . Do you remember other simple or famous cases of
> implicit conversions of the standard library?

My first favorite is how 'false' converts to null pointer.

std::string foo()
{
return false;
}

At least compilers have started to warn on that one in recent few years.

Second of my favorite is how implicit conversions screw up the new (too
loose) initialization.

void bar()
{
// a is vector with one element
std::vector<std::string> a{{"hello"}};

// !!! :( !!! b is vector with one undefined behavior element
std::vector<std::string> b{{"hello", "there"}};

// c is vector of three elements
std::vector<std::string> c{{"hello", "there", "kids"}};
}

AFAIK no compiler warns here.

'b' breaks since is it now implicit literal-to-pointer-to-string
conversion or literal-to-pointer-to-iterator conversion?

C++ compiler resolves that ambiguity aggressively and silently and
chooses latter by language rules.

These are quite hard to explain it to novice.