CODEWITHSUNDEEP
c++castingtype-conversion
Martin Meeser
Martin Meeser

Reputation: 2956

C++ string (const char[1]) to bool type conversion - reason/explanation and consequences

Take a look at following C++ code:

// imagine 10.000 lines if C++ here

bool test() {
   // imagine 300 loc here 
   return "";
}

int main(int argc, char** argv) {
    bool whaaaaaat = test();
    return 0;
}

When you compile those lines the result is:

BUILD SUCCESSFUL (total time: 208ms)

There is even NOT a warning!

Please confirm:

  1. "" is treated by C++ compiler as char[1] aka char*
  2. which is then converted to bool
  3. which is always != 0 => always true

Question: When the program continues, will there be any negative impact on the state of the program (broken memory?).

This setup is really dangerous, the compiler should at least give a warning!

Upvotes: 0

Views: 2111

Answers (5)

eerorika
eerorika

Reputation: 238411

"" is treated by C++ compiler as char[1] aka char*

In very inexact terms, yea sort of. To be more exact, "" is a const char[1], and const char arrays can decay to const char* which points to the first (only in this case) character.

which is then converted to bool

which is always != 0 => always true

Exactly yes, to both.

Question: When the program continues, will there be any negative impact on the state of the program (broken memory?).

No broken memory, or any other negative impact. The behaviour is well defined. This function would be effectively the same:

bool test() {
    "";
    return true;
}

This setup is really dangerous

I don't agree. It's pointless at most.

The question is about a function returning always true, without any warning or error of the compiler, that is just the condensed example.

I don't think that warrants a warning, much less an error.

Consider an interface that is an abstraction over different kinds of processes, that returns true on success. Now consider implementing that interface, knowing that your simple process never fails, and therefore always returns true. Should the compiler prevent you from writing such implementation? Should it even pester you with a warning? Not in my opinion.

do you think gdb might be affected?

No.

Upvotes: 2

songyuanyao
songyuanyao

Reputation: 172984

It's well defined as boolean conversions (one of implicit conversions):

A prvalue of integral, floating-point, unscoped enumeration, pointer, and pointer-to-member types can be converted to a prvalue of type bool.

The value zero (for integral, floating-point, and unscoped enumeration) and the null pointer and the null pointer-to-member values become false. All other values become true.

For your code, "" might decay to pointer (i.e. const char*) which is not null, so the result will be true. For pointers, it just checks whether it's null or not and returns a bool which is true or false, it'll be fine (no "broken memory" :) ).

Upvotes: 1

mooncheese
mooncheese

Reputation: 124

No negative effects, just bad(too hard to unserstand) style of coding. I saw such code in old many year working project

assert(somethingIsRight && "Something is wrong!");

Upvotes: 1

Sergey Kalinichenko
Sergey Kalinichenko

Reputation: 726849

"" is treated by C++ compiler as char[1] aka char**

"" is treated as an array of one constant char. It is not the same as char*, although under some circumstances it could be converted to const char* (const-ness is specific to C++).

which is then converted to bool which is always != 0 => always true

Correct on both points.

When the program continues, will there be any negative impact on the state of the program (broken memory?)

There are absolutely no consequences to this: no memory leaks, no dangling pointers, or other bad things.

Upvotes: 1

Lightness Races in Orbit
Lightness Races in Orbit

Reputation: 385284

You are basically correct.

Your string literal char const[1] will decay to char const* and, as with any pointer, booleanisation will tell you whether it's null or not. This one isn't.

I would generally tend to agree that this implicit conversion is dangerous, but only because the behaviour of your program may not be quite what you wanted it to be. There's no "broken memory".

Upvotes: 4

Related Questions