forcing value to bool 'true' or 'false' (performance warning)

I'm perusing source code (code I didn't write but I'm now trying to maintain) that has a litany of get and set methods within various message classes. The get methods within these class return - for the most part - enumerated types (and there's lot of flavors) or unsigned short.

The values of the get methods is then stored into a 'bridge'. Trouble is, the bridge class has a mix of unsigned shorts and bool as types. This was done to keep things 'generic'. IOW: The bridge shouldn't care about enumerated types.

For simplicity here's a contrived example:

Code:

---

# include <iostream>
enum Overall_Status
 {
  Overall_Status_UNUSED = 0,
  Overall_Status_PASSED = 1
 } ;
class test {
  unsigned short x ;
public :
  test( unsigned short x_ )
  : x ( x_ ) {}

  Overall_Status GetMethod () {
  return ( static_cast < Overall_Status > ( x )  ) ;
  }
};
int main() {
  test f ( 1 ) ;
  bool  xx                = f.GetMethod ( ) ;      //[1]
  unsigned short yy =  f.GetMethod ( ) ;    //[2]
  Overall_Status zz =  f.GetMethod ( ) ;    //[3]
  std::cin.get();
}

---

Alas, I'm now faced with 384 warnings I have to fix. Warnings akin to the one shown above via item [1]. i.e:
warning C4800: 'Overall_Status' : forcing value to bool 'true' or 'false' (performance warning)


My solutions thus far (can't muck with the return types on the messages):
a) use an unsigned short (2 bytes on the implementation - so I use an extra byte - bool is 1 byte on the implementation) -- see [2] above
b) Modify the bridge types to match the types in the message classes -- see [3] above
c) ??????? <not sure>
Thoughts!

Code:

---

bool  xx = (f.GetMethod ( ) == whatever_you_say_means_true)?true:false;

---

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

Code:

---

bool  xx = (f.GetMethod ( ) == whatever_you_say_means_true)?true:false;

---

Regards,

Paul McKenzie

---

Good point!..

Quote:

---

Originally Posted by Paul McKenzie

Code:

---

bool  xx = (f.GetMethod ( ) == whatever_you_say_means_true)?true:false;

---

---

That's pretty redundant, no?

I suppose the ternary operator part would be redundant, but other than that:

Code:

---

bool xx = f.GetMethod() != Overall_Status_UNUSED;

---

Don't use an enum.

Just define them as

const bool Overall_Status_UNUSED = false;
const bool Overall_Status_PASSED = true;

As a side note, most of the suggestions (except GCDEF's) are eplicit implementations of the performance degradition that the compilerabout when implicitly implementing identical logic). All they have done is to remove the warning and not address the issue. GCDEF is the only one who has proposed a solution that actually avoids the conditional branching (which does nasty things like flushing pipelines, etc)

Quote:

---

Originally Posted by TheCPUWizard

As a side note, most of the suggestions (except GCDEF's) are eplicit implementations of the performance degradition that the compilerabout when implicitly implementing identical logic). All they have done is to remove the warning and not address the issue. GCDEF is the only one who has proposed a solution that actually avoids the conditional branching (which does nasty things like flushing pipelines, etc)

---

That is true, but I think that GCDEF's suggestion does not address the issue at all, since the enum appears to be required (see the original post on "enumerated types (and there's lot of flavors)") even though it is unnecessary in the example.

Quote:

---

Originally Posted by laserlight

That is true, but I think that GCDEF's suggestion does not address the issue at all, since the enum appears to be required (see the original post on "enumerated types (and there's lot of flavors)") even though it is unnecessary in the example.

---

Agreed. I was just was pointing out that the conversion to a boolean will (almost) always involve a comapre and BRANCH operation. In many ways the compiler warning and manual implementation (simply to avoid the warning) provides NO performance advantages, and in some cases may just clutter up code.

The underlying functional desire should be considered and the appropriate action (possibly a design change) taken on a case-by-case basis.

Quote:

---

Originally Posted by laserlight

I suppose the ternary operator part would be redundant, but other than that:

Code:

---

bool xx = f.GetMethod() != Overall_Status_UNUSED;

---

---

True but what about the reverse direction. Again contrived example:

Code:

---


class test {
  Overall_Status x ;
public :
  test( Overall_Status x_ )
  : x ( x_ ) {}
  void SetMethod ( Overall_Status x_ )  {
    x = x_ ;
  }
  Overall_Status GetMethod () {
  return ( x ) ;
  }
};

int main( void )
{ 
  test f ( Overall_Status_UNUSED ) ;
  bool xx =  ( f.GetMethod ( ) == Overall_Status_PASSED ) ? true : false;

  f.SetMethod ( ( xx == true ) ? Overall_Status_PASSED : Overall_Status_UNUSED  ) ; 
 
  std::cin.get();
}

---

The call to SetMethod now requires conditional logic.

Quote:

---

Originally Posted by TheCPUWizard

The underlying functional desire should be considered and the appropriate action (possibly a design change) taken on a case-by-case basis.

---

I'm starting to think a possible redesign, though my schedule doesn't reflect time for that. The code uses what I'll call - a push/pull model. A message is first pushed into the bridge. A notification is sent via the use of the observer pattern where observers observe/attach to message types (IOW: Observers extract only what of interest to them from the message that was placed into the bridge). Observers in this case pull messages from the bridge. Now I'm thinking out loud here so it's quiet possible this doesn't make sense, in any event, the question: Instead of having matching message** and bridge types, is it possible to make the types in the bridge 'adaptable'? Simply put during updates to the bridge the bridge will take on the message types?

** matching message and bridge types is not feasible because the enumerated types on both sides (see below) aren't the same.
[msg type side a] <===> [bridge] <====> [msg type side b]

Quote:

---

Originally Posted by mop65715

True but what about the reverse direction.

---

The "reverse direction" may be impossible, since the bool might not provide enough information to decide which of the enumerators to choose. If you really did want to do that without changing the enum to bool, I suppose I might write:

Code:

---

bool xx = f.GetMethod( ) == Overall_Status_PASSED;

f.SetMethod( xx ? Overall_Status_PASSED : Overall_Status_UNUSED );

---

Quote:

---

Originally Posted by Paul McKenzie

Code:

---

bool  xx = (f.GetMethod ( ) == whatever_you_say_means_true)?true:false;

---

Regards,

Paul McKenzie

---

I think this suggestion is spot-on. But assuming the implementors of this bridge object knew what they were doing, I think they were wanting to use bool to represent non-zero enums. So, instead if finding out which enum to match to for all the test classes, I think only this will suffice:

Code:

---

bool xx = f.GetMethod() != 0;

---

For removing these kind of warnings

Replace : 'bool' with 'BOOL' in declaration of the bool variables.

Replace : 'true' with 'TRUE' and 'false' with 'FALSE' values if anywhere in the code, for these variables.

If you declared 'BOOL', then values should be 'TRUE' or 'FALSE' - In These kind of declaration, it convert 'int' to 'bool' without typecasting.

If you declared 'bool' then values should be 'true' or 'false' - In These kind of declaration, if 'int' value is passed to 'bool' variable then you will get warning "forcing value to bool 'true' or 'false' (performance warning)" .


( I tried in VC++ .Net 2003) May be it will work for VC++ Version 6 also.

Quote:

---

Originally Posted by ranjithan

For removing these kind of warnings

Replace : 'bool' with 'BOOL' in declaration of the bool variables.

Replace : 'true' with 'TRUE' and 'false' with 'FALSE' values if anywhere in the code, for these variables.

---

This is not a portable solution.

My advice, only use BOOL if you're calling a Windows API function, or if you're creating a Windows DLL and you're returning a value or one of your parameter values is BOOL (since "bool" is only a C++ invention).

If you're using BOOL in your own, non-Windows API/DLL, C++ code, rethink what you're doing and use bool instead.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

This is not a portable solution.

My advice, only use BOOL if you're calling a Windows API function, or if you're creating a Windows DLL and you're returning a value or one of your parameter values is BOOL (since "bool" is only a C++ invention).

If you're using BOOL in your own, non-Windows API/DLL, C++ code, rethink what you're doing and use bool instead.

Regards,

Paul McKenzie

---

you can make use of the operator ! which will return bool. See the code snippet below.

BOOL bResult = FALSE;
...

bool bReturnValue = !!bResult;


Another interesting one is it can be used to reduce code unwanted code blots.
See the following code block.

bool Function()
{
// Member which holds return in bool.
bool bReturn = false;

// Assume FnWhichReturnsBOOL is a function
// which returns BOOL.
if( FALSE != FnWhichReturnsBOOL())
{
// Since its success, set return as true.
bReturn = true;
}

return bReturn;
}

This can be easly re-written as follows

bool Function()
{
BOOL bReturn = FnWhichReturnsBOOL();
return bReturn != FALSE;
}

Quote:

---

Originally Posted by ranjithan

you can make use of the operator ! which will return bool. See the code snippet below.

---

Here is the point I'm making:

There is no such thing as "BOOL" in C++ -- that is a Windows invention, and it isn't portable (note this is a non-Visual C++ forum). A "bool" is C++ and can be used anywhere a compliant C++ compiler exists, whether it's Windows, UNIX, Mac, or any other operating system.

That's why if you're writing C++ code, and not using the Windows API, you use "bool". Just because a popular OS API uses "BOOL" doesn't make it good to use in any C++ program (and you definitely can't use it if you're on Linux).

Regards,

Paul McKenzie

It's funny, because JUST TODAY, I fell on this in one of my pieces of code:

Code:

---

bInstallCanceled = ITevent.IsITRaised()?true:false;

---

And I was like: ***?
Turns out IsITRaised returns a BOOL (read int), and indeed, the ternary operator suppressed a warning (bInstallCanceled is a normal bool).

I really hate the windows API :(

Quote:

---

Originally Posted by monarch_dodra

It's funny, because JUST TODAY, I fell on this in one of my pieces of code:

Code:

---

bInstallCanceled = ITevent.IsITRaised()?true:false;

---

And I was like: ***?
Turns out IsITRaised returns a BOOL (read int), and indeed, the ternary operator suppressed a warning (bInstallCanceled is a normal bool).

I really hate the windows API :(

---

The problem is that the Windows API is 'C' based, so there really is no such type as "bool" for 'C' programmers. So BOOL was invented for 'C' programmers to denote TRUE or FALSE. So the only solution (and really, correct solution) is to convert the int to the proper bool value.

You're lucky that the original API didn't make TRUE equal to -1, which is what a lot of Windows-based languages seem to do. That code may not have worked correctly without the ternary if that were the case (although I need to see the ANSI spec on that one).

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

You're lucky that the original API didn't make TRUE equal to -1, which is what a lot of Windows-based languages seem to do. That code may not have worked correctly without the ternary if that were the case (although I need to see the ANSI spec on that one).

---

I'm pretty sure that in C++, the only standard is 0 is false, everything else is true. So even if -1 means true, the code should work, even without the ternary operator.

What is problematic are those functions that return 0 when everything is fine, and non zero for error code.