enum promote to bool type rather than Integer type?
FE
TIXML_SUCCESS==retcode
warning c4805 "==" :no safe with bool and integer
TIXML_SUCCESS is a enum type in tinyxml lib
but
retcode==TIXML_SUCCESS
no warning!
why?
Jonathan Lee
> TIXML_SUCCESS==retcode
> warning c4805 "==" :no safe with bool and integer
> retcode==TIXML_SUCCESS
> no warning!
>
> why?
I don't know why reversing the order of the operands
doesn't produce the same warning, but I would avoid
both uses. Because of the integral promotion of the
boolean value, the code might not actually do what
you intend.
For example, "if(3){}" will execute because 3 is
converted to the boolean value true. But
"if(3 == true){}" will not execute because true
is promoted to 1, an int, which is not equal to 3.
If I were reading the latter, I wouldn't be sure
which behaviour the author wanted. A cast would
let me know, and it would get rid of the warning,
too.
--Jonathan
Vladimir Jovic
Can you post some real code what exactly you did? That comparison should
work fine (if you used it correctly).
Balog Pal
> vc2008
>
> TIXML_SUCCESS==retcode
> warning c4805 "==" :no safe with bool and integer
That is a very good warning, and one better treated as error.
Especially as we have many hidden cases lurking, habing BOOL, Bool, and
similar replacements that may be bool or char or int depending on a whim.
Bringing in possibility to containv alue other than 0 and 1, and the test
doing not what intended.
Comparision with true/false is marked 'avoid' in many guidelines too.
> TIXML_SUCCESS is a enum type in tinyxml lib
>
>
> but
> retcode==TIXML_SUCCESS
> no warning!
Can you show some real-life problem this is likely to cause? using int in
place of enum is pretty common due to lack of ability to forward-declare the
enum. At the use place the values normally meet. (in C++0x there are
serious enhancements to enum, so the programmer tune conversions)
FireEmissary
enum
{
TIXML_SUCCESS,
TIXML_NO_ATTRIBUTE,
TIXML_WRONG_TYPE
};
#define EXCEPTION_PARSER(T) do{if(!T)throw InnateException();}while
(0)
int retcode=todoElement->QueryIntAttribute
("active_per_lay",&ActivedNumPerLay);
EXCEPTION_PARSER(retcode==TIXML_SUCCESS);
I forget In brackets. so EXCEPTION_PARSER
(retcode==TIXML_SUCCESS);expand to
do ({if(!TIXML_SUCCESS==retcode)throw InnateException();}while(0)
must to be EXCEPTION_PARSER((retcode==TIXML_SUCCESS));
Michael Doubez
It is a matter of operator precedence: operator ! has more precedence
than operator ==, which mean that :
!TIXML_SUCCESS==retcode
is interpreted as
(!TIXML_SUCCESS)==retcode
You'd rather put the brakets in the macro (as the usual advice goes):
#define EXCEPTION_PARSER(T) do{if(!(T))throw InnateException();}while
(0)
IMHO you don't get the warning in the case of:
!retcode==TIXML_SUCCESS
because for some reason, it interprets TIXML_SUCCESS as 0 (false) and !
retcode is a valid boolean while
!TIXML_SUCCESS==retcode
is equivalent to
true == retcode
which is more problematic.
--
Michael
Balog Pal
> #define EXCEPTION_PARSER(T) do{if(!T)throw InnateException();}while
> (0)
for macros () is a must, around the arguments where used...