Re: equality operator question
On May 6, 12:52 pm, Pete Becker <p...@versatilecoding.com> wrote:
On 2008-05-06 02:58:01 -0400, Krice <pau...@mbnet.fi> said:
Pete Becker kirjoitti:
int i = get_some_value();
Why would anyone mix int with bool true or false?
Often a function returns a value that indicates whether it
succeeded, and if not, an error code that indicates what the
failure was. Sometimes all you care about is whether it
succeeded. There's a long tradition in C and C++ of using this
kind of bool-and-a-half value.
But you wouldn't mix the int with true or false.
At least in the C/C++ communities I've been active in, the
largest single tradition involved defining sentinal values to be
used for an error: typically, a function which can only return
positive values will be declared to return an int, with -1 for
error. Which, of course, doesn't lend itself to an implicit
conversion, much less with comparison with true or false.
More recently, of course, Posix has adopted the tradition of
returning 0 for success, and a strictly positive error code for
error, so you could write:
if ( pthread_create( ... ) ) {
// Didn't work...
}
Which, of course, is exactly the opposite convention that one
finds in:
if ( std::getline( input, line ) ) {
// Worked...
}
Here too, however, you wouldn't mix with true or false; you
wouldn't write:
if ( pthread_create( ... ) == false ) {
// Worked...
}
(and of course:
if ( pthread_create( ... ) == true ) {
// Didn't work...
}
doesn't work at all.)
Globally, I find the convention of "true" for success slightly
more intuitive, but it doesn't leave any possibility for
additional error codes. I'll use the direct test on the
operation with iostream, because it is *the* standard C++ idiom,
but in all other cases, I'll use comparison.
At least where "simple" types are concerned. In more complex
cases, I've found it useful to return a class with the error
status and additional information. And to have the class
convert implicitly to bool. But here again: I only use the
conversion (the bool) for a direct check, where I don't need any
of the additional information---I don't compare the results with
true or false.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34