Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Paul Dolhai

forcing value to bool

This topic is 5960 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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++]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
Guest 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). 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

Share this post


Link to post
Share on other sites
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++]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Exceptions are not free.
Exceptions are not universally available; particularl environments may not have them, interopability constraints may not permit them.
And most importantly, most error conditions are not exceptional. Exceptions should be rare. But errors may not be (for instance, wherever you have to trust a user to do something sensible, you have scope for errors).

As for allowing one to "centralise sic." error checking, that entirely depends on what you want your error-checking to do.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!