equality fails with C++ bools
I have a function declared bool that is acting rather non-bool. std::cout << obj.fn() gives me "76" and BOOST_CHECK_EQUAL(obj.fn), true) fails, with the message /home/ross/peter/R/mspath/src/test/Covariates_test.cc(178): error in "obs_covariates": test env.matchesObservation() == true failed [76 != 1] std::cout << true prints "1". obj.fn() works OK as an argument to if (obj.fn()). I am using g++ 1:3.3.5-5 on Debian GNU/Linux. I've tried -O2 and -O1; same behavior either way. boost is 1.31.0-9 The function is declared bool matchesObservation() const Maybe bool is being typedef'd or #define'd to int somewhere, for compatibility with old code? Probably not; I tried printing typeid(xxx).name() and got "b" for true and the function return value, while I got "i" for the number 1. I tried tracing into the code with limited success. Some mix of the fact that the underlying libraries weren't a debug version, that the code was optimized, and that there are #line directives (the source files were generated out of another file) made it hard to follow. Any suggestions? -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062
A couple of follow up points. The function that seems to be returning the funny value is defined only in a header file. I am completely unable to get a bool that prints as anything but 1, even when I initialize it with another value or overwrite the same memory location with another bit pattern. (obviously I didn't try false or 0). The strange behavior persists at -O0 and with -fno-default-inline. With those settings I see in the debugger that the original variable from which the value is taken is a boolean with value 76. The test fails even if both sides get static_cast<bool>
std::cout << obj.fn() gives me "76" and BOOST_CHECK_EQUAL(obj.fn), true) fails, with the message [...] Any suggestions?
I do not know what is going on with your bool. But I would suggest using BOOST_CHECK tool instead for checking result of a function returning bool. In this case it wouldn't matter if true is 1234 in fact. Gennadiy
On Sat, Jan 29, 2005 at 10:55:23AM -0500, Gennadiy Rozental wrote:
std::cout << obj.fn() gives me "76" and BOOST_CHECK_EQUAL(obj.fn), true) fails, with the message [...] Any suggestions?
I do not know what is going on with your bool. But I would suggest using BOOST_CHECK tool instead for checking result of a function returning bool. In this case it wouldn't matter if true is 1234 in fact.
Gennadiy
I prefer the symmetry of BOOST_CHECK_EQUAL(obj.fn(), true) BOOST_CHECK_EQUAL(obj.fn(), false) since, at different points I'm expecting true or false. I know there are alternatives. Originally I thought this problem might have something to do with the particulars of BOOST_CHECK_EQUAL, but it seems not to. For example, cout << obj.fn() returns 76 outside of the BOOST_CHECK_EQUAL context, and I also see (using gdb) 76 as the value for the instance variable that is the source of the data being returned. My inspection of the source code, as well as the type info given interactively by gdb, shows that everything involved is boolean. Conceivably something, somewhere in the boost headers has something to do with this. Unfortunately, my efforts to replicate with a simple case have so far been fruitless. I found nothing relevant on the gcc bug list, and the word "bool" doesn't even appear in the changelog. Ross
On Sat, Jan 29, 2005 at 01:52:53PM -0500, Gennadiy Rozental wrote:
I prefer the symmetry of BOOST_CHECK_EQUAL(obj.fn(), true) BOOST_CHECK_EQUAL(obj.fn(), false) since, at different points I'm expecting true or false. I know there are alternatives.
Why not BOOST_CHECK( obj.fn() ); BOOST_CHECK( !obj.fn() );
I believe it's more natural.
Gennadiy
I was probably also influenced by a literal-minded reading of the useage suggestion "Prefer BOOST_CHECK_EQUAL to BOOST_CHECK"! As it turns out, I'm lucky I used the BOOST_CHECK_EQUAL form, because it exposed this bug. The returned value tested as true, but not == true. I was using an uninitialized (actually, post-destruction) value for the bool, and that's what led to the crazy value. I reported earlier that overwriting the bits in the bool variable did not change it. That report was mistaken; at least, when I try it now I am able to stick numeric values in the bool other than 0 or 1. I know using unitialized or free'd variables is a no-no, but I'm a bit surprised bool can take on such wacky values.
participants (2)
-
Gennadiy Rozental -
Ross Boylan