Has anyone ever gotten this warning before? warning C4800: ''int'' : forcing value to bool ''true'' or ''false'' (performance warning) I have a function int NewWindow(...), in which all the returns are in the form return FALSE or return TRUE, and an if statement if (!App.m_Window.NewWindow(..) ; I''ve changed my NewWindow function to return bool instead and it still gives me the same warning. The weird thing is I remember having this error before and I fixed it somehow, but I can''t this time . Thanks Paul

quote:Original post by Paul Dolhai
Has anyone ever gotten this warning before?

No. Nobody has ever had that warning before. You are the world''s first person ever to see such a warning.

Seriously, though... FALSE and TRUE are MS typedef''s for integer 0 and 1, respectively. Rewrite these as lower-case false and true, which are the correct values for the C++ bool type.

[C++ FAQ Lite | ACCU | Boost | Stroustrup on Learning C++]

And change your NewWindow signature to return bool. That, or change your if statement to look like if( App.m_Window.NewWindow != TRUE ) (which is messier, IMO).

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

if you''re using bool, use true/false as return types. If you''re using BOOL, then use TRUE/FALSE as return types.
Personally I always use a char or an unsigned char for my return type, and just return a 0 or a non-0. That way I can do a simple...
if (!FunctionPassed())
{
//Function failed!
return -1;
}

or...

char Ret=FunctionPassed();
if (!Ret)
{
switch (Ret)
{
1: printf("Out of memory"; break;
2: printf("File not found"; break;
3: printf("Some other error"; break;
};
return -1;
}

This way, I can return errors, and I can check for errors (I don''t have to, but I can if I want to, helps for debugging sometimes), but it''s no more CPU intensive than using a bool, and less memory intensive than using a BOOL. A BOOL is stored as an integer.. which is 32-bits in MSVC++, while my method only uses a char, which is 8-bits in MSVC++.

Billy - BillyB@mrsnj.com

quote:Original post by Anonymous Poster
This way, I can return errors

That''s what exceptions are for.

[C++ FAQ Lite | ACCU | Boost | Stroustrup on Learning C++]

Why would I use exceptions... I like using unsigned chars for return types, and checking them with switch or if statements... makes my life simple. I find it easy to debug while using numbers for returns, as I can watch them in the debugger, I can use it in the released code if it does something useful, like check for missing files, or memory allocation problems, and it has NO over-head if everything passes (I mean, no over-head, not even memory/file size wise). I just never got into that hole exception thing, and I really don''t care to as my method works fine for what I need/use it for. I can also use my unsigned char as a flag, so I can accumulate errors in a function, and return them all at once.

unsigned char SettingsOk()
{
unsigned char Ret=0;
if (!KeyBoardSet)
Ret|=1;
if (!MouseSet)
Ret|=2;
if (!InitFileSet)
Ret|=4;
return Ret;
}


unsigned char Ret;
Ret = SettingsOK();
if (!Ret)
{
GenericSettings(Ret); //Set generic settings based on our flag!
}

Ok, I realize that this isn''t the best example, but you can get the gist of what I''m doing. I could use a global variable to hold this.. but we know global''s = bad right... we couldn''t really throw exceptions to do this, could we? We can either check Ret, and set the settings, or just do a simple if (!SettingsOK()) return -1;

Anyways, this is my coding style/habit, and I tend to like it''s ease of use, and efficiency. I have yet to hit any limitations of using this method, and until I do so, I will continue to use it.

Billy - BillyB@mrsnj.com

quote:Original post by Anonymous Poster
Why would I use exceptions...

Because that''s what they''re for? Because they allow you to isolate error handling from normal application code? Because you can centralise error handling policy to just a few places? Because they allow separation of concerns? Other than that, I don''t know.

quote:
I just never got into that hole exception thing, and I really don''t care to as my method works fine for what I need/use it for.

Ahh... so your objection is based on superstition and habit? You apparently have no objection to using exceptions, but rather an objection to using anything other than what you are used to. Is that a fair analysis?

[C++ FAQ Lite | ACCU | Boost | Stroustrup on Learning C++]

quote:Original post by SabreMan
No. Nobody has ever had that warning before. You are the world''s first person ever to see such a warning.

I guess I had that coming. Anyways thanks for the quick replies.

quote:Original post by Anonymous Poster
Why would I use exceptions... I like using unsigned chars for return types, and checking them with switch or if statements... makes my life simple. I find it easy to debug while using numbers for returns, as I can watch them in the debugger, I can use it in the released code if it does something useful, like check for missing files, or memory allocation problems, and it has NO over-head if everything passes (I mean, no over-head, not even memory/file size wise.

Your method clearly has an overhead. You have the overhead of returning the error code and checking it manually. If you talk about exceptions have overhead you have to think about what you are comparing it to. I cannot see your method having any speed benifits at all.

Also, it looks very messy because your mixing normal code with error handling code and everytime you call one of your functions you''ll need another set of if statements. What happenes when you need to add a new return value? Your going to have to change every switch statement. Also, branches are harder to debug and there is more scope of logic errors (e.g. missing a break; statement).

Don''t take this the wrong was but you appear to prefer your method out of ignorance of how exceptions work.