Reply to thread

Message: [QUOTE="James Kanze, post: 3791459"] Yes. But that's an implicit conversion (and a lossy one, at that)---a bit of obfuscation, if you prefer, present mainly for reasons of backwards compatibility. Or, perhaps, as a technical means of supporting what Andy seems to be arguing for: conditions that don't really require booleans. (Sort of like saying, in English "if the address", rather than "if the address is present", or "if the address is valid".) And the fact that it uses key words like if and while, who's meaning in English implies a predicate, is also irrelevant? That's what I mean when I said it seems like an oxymoron. Saying that we have an if that tests something that isn't a predicate seems to me an internal contradiction. I can sort of understand his point of view (although I still don't agree) IF we accept the idea of "null", in the data base sense. This has serious repercussions, however; if we implement it systematically, all types should be "null-able", so even bool ends up with three states (true, false and null), and "if ( aBool )" executes the if clause if aBool is true or false (but not if it is null). I don't think that's really a direction C++ wants to take. (While I can partially see the argument for "if (pointer)"---a null pointer is a very special, sentinal value---I can't accept it at all for "if (number)", where number is a double or an int. There's nothing particularly special about 0, and for example, open(), under Unix, uses -1 as its special return value.) In the end, C++ has taken the route of increasing type safety (compared to C). Not quite as much as it should, IMHO---I'd like to see implicit conversions of double to int, for example, dropped. But the type system is important in C++. And explicitly providing a bool in a condition is part of that type system; supporting things like "if (p)" is a crack in that type system. [/QUOTE]

Verification