• Advertisement

Archived

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

forcing value to bool

This topic is 5790 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
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!

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
quote:
Original post by DrPizza
Exceptions are not free.

Nobody said they were.
quote:

Exceptions are not universally available; particularl environments may not have them, interopability constraints may not permit them.

But we''re not talking about any of those environments.
quote:

And most importantly, most error conditions are not exceptional.

Which is a reasonable statement. However, it would appear Paul has already decided that a bool is sufficient to capture the needed return value from his function for the "normal" flow of control to continue. Once that decision has been made, I don''t see any need to clutter the code with transporting exceptional error information along with the standard processing, as the AP was suggesting. For example, he had an "out of memory" return code in his example, and I wanted to find out what his specific objection was to using exceptions to transport that sort of information.


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

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
But we''re not talking about any of those environments.

We don''t know that.

quote:
Which is a reasonable statement. However, it would appear Paul has already decided that a bool is sufficient to capture the needed return value from his function for the "normal" flow of control to continue. Once that decision has been made, I don''t see any need to clutter the code with transporting exceptional error information along with the standard processing, as the AP was suggesting. For example, he had an "out of memory" return code in his example, and I wanted to find out what his specific objection was to using exceptions to transport that sort of information.

This is rather beside the point; my objection is to your "that''s what exceptions are for". I don''t agree that they are; exceptions are for indicating something exceptional has happened. Return values are for indicating non-exceptional success/failure conditions.

The AP''s post did, however, mix the two; under most circumstances, running out of memory is exceptional; under most circumstances, a file not being found is not. So whilst some of those error conditions arguably should have been trapped with exceptions, leaving others as return values still strikes me as the correct thing to do.



As for Paul''s, I think he''d be better off returning 0 for success, non-zero for particular errors (and not the same non-zero value, either; something you can test and react to if you need to) and exceptions for exceptional circumstances. It may be that he has no exceptional and/or non-exceptional failure modes for this function, but we can''t tell.

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
We don''t know that.

I''m *very* sure we are talking about MSVC++.
quote:

This is rather beside the point;

It''s not beside my point. My point being that I wanted to know why Billy objects to exceptions, particularly in code where he is checking for such conditions as running out of memory.
quote:

my objection is to your "that''s what exceptions are for". I don''t agree that they are; exceptions are for indicating something exceptional has happened. Return values are for indicating non-exceptional success/failure conditions.

Yes, that doesn''t contradict my understanding in any way, and is something I''ve been telling people for several years. However, that does nothing to help me understand Billy''s reasoning. I *know* what my thoughts on exceptions are, and now I know what your thoughts are. However, you''re not the person who posted the code that I was curious about.


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

Share this post


Link to post
Share on other sites
quote:
I''m *very* sure we are talking about MSVC++.

I dunno about you, but I''ve written code in MSVC++ that''s had to be called from other languages and other compilers; if that function were exported from a DLL, for instance, there''s no way I''d advocate throwing an exception, because there''s no way of knowing what the calling code is going to make of it.

Share this post


Link to post
Share on other sites
quote:
It''s not beside my point. My point being that I wanted to know why Billy objects to exceptions, particularly in code where he is checking for such conditions as running out of memory.

It''s entirely beside the point. I don''t care why Billy says to do something -- I only care that you said, in response to Billy''s statement "I can return errors", "this is what exceptions are for". No, they''re not. Exceptions are for describing the exceptional. Return values are for describing success/failure.

quote:
Yes, that doesn''t contradict my understanding in any way,

I''m sorry?

Billy says "I can return errors".

You say "that''s what exceptions are for".

I say "no it isn''t, they''re for indicating exceptional events; errors are for return values".

That certainly contradicts your stated (even if not intended) position.

quote:
and is something I''ve been telling people for several years. However, that does nothing to help me understand Billy''s reasoning. I *know* what my thoughts on exceptions are, and now I know what your thoughts are. However, you''re not the person who posted the code that I was curious about.

This is beside the point. We''re not talking about Billy''s motivations, we''re talking about your claim that exceptions are the mechanism for returning error values. They are not.


Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
This is beside the point. We''re not talking about Billy''s motivations, we''re talking about your claim that exceptions are the mechanism for returning error values. They are not.

So, apparently, in fixating on an earlier post where admittedly, I didn''t state my point too well, you have conveniently ignored a more recent post of mine.


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

Share this post


Link to post
Share on other sites

  • Advertisement