Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #7865 > unrolled thread

Implicit convervsion of bool to int: why?

Back to article view | Back to comp.lang.c++

Contents

  Implicit convervsion of bool to int: why? "MikeP" <mp011011@some.org> - 2011-07-16 04:29 -0500
    Re: Implicit convervsion of bool to int: why? Krice <paulkp@mbnet.fi> - 2011-07-16 02:37 -0700
      Re: Implicit convervsion of bool to int: why? "MikeP" <mp011011@some.org> - 2011-07-16 04:43 -0500
        Re: Implicit convervsion of bool to int: why? BGB <cr88192@hotmail.com> - 2011-07-16 02:54 -0700
          Re: Implicit convervsion of bool to int: why? Abhishek Padmanabh <abhishek.padmanabh@gmail.com> - 2011-07-16 18:52 +0100
            Re: Implicit convervsion of bool to int: why? BGB <cr88192@hotmail.com> - 2011-07-16 23:03 -0700
              Re: Implicit convervsion of bool to int: why? Abhishek Padmanabh <abhishek.padmanabh@gmail.com> - 2011-07-17 09:02 +0100
                Re: Implicit convervsion of bool to int: why? BGB <cr88192@hotmail.com> - 2011-07-17 02:04 -0700
    Re: Implicit convervsion of bool to int: why? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-16 22:28 -0500
      Re: Implicit convervsion of bool to int: why? "MikeP" <mp011011@some.org> - 2011-07-17 00:02 -0500
        Re: Implicit convervsion of bool to int: why? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-17 02:04 -0500
          Re: Implicit convervsion of bool to int: why? "MikeP" <mp011011@some.org> - 2011-07-17 05:38 -0500
          Re: Implicit convervsion of bool to int: why? "MikeP" <mp011011@some.org> - 2011-07-20 05:14 -0500
        Re: Implicit convervsion of bool to int: why? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-07-30 13:18 +0300
          Re: Implicit convervsion of bool to int: why? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-07-31 13:48 +0300
    Re: Implicit convervsion of bool to int: why? James Kanze <james.kanze@gmail.com> - 2011-07-20 11:08 -0700

#7865 — Implicit convervsion of bool to int: why?

Why can bool types be implicitly converted to ints? Wouldn't it be better 
if a bool was a bool was a bool was a bool...? The complementary question 
is also a curiosity: why can an int be converted to a bool? I think the 
answer to the last question has to do with "trueness" in C++ historically 
meaning "not zero" instead of meaning "one". 

[toc] | [next] | [standalone]

#7866

On 16 heinä, 12:29, "MikeP" <mp011...@some.org> wrote:
> Wouldn't it be better
> if a bool was a bool was a bool was a bool...?

Yes, it's better. Don't mix bools and ints, they are different types.

[toc] | [prev] | [next] | [standalone]

#7867

Krice wrote:
> On 16 heinä, 12:29, "MikeP" <mp011...@some.org> wrote:
>> Wouldn't it be better
>> if a bool was a bool was a bool was a bool...?
>
> Yes, it's better. Don't mix bools and ints, they are different types.

I was asking WHY they did that (mixed up bools and ints) in C++. 

[toc] | [prev] | [next] | [standalone]

#7869

On 7/16/2011 2:43 AM, MikeP wrote:
> Krice wrote:
>> On 16 heinä, 12:29, "MikeP"<mp011...@some.org>  wrote:
>>> Wouldn't it be better
>>> if a bool was a bool was a bool was a bool...?
>>
>> Yes, it's better. Don't mix bools and ints, they are different types.
>
> I was asking WHY they did that (mixed up bools and ints) in C++.
>

because C++ came directly from C, which generally didn't/doesn't have 
bool (a "_Bool" type was added in C99, but is not so often used).

in C tradition, zero means false and non-zero means true, and C++ mostly 
just followed suit, making relatively few changes to the fundamental C core.


possibly because in many languages, whether or not zero/non-zero can 
represent false/true is a matter of debate, with many languages allowing 
this and others rejecting it, so it is not such a clear-cut matter 
in-general.


or such...

[toc] | [prev] | [next] | [standalone]

#7881

On 7/16/2011 10:54 AM, BGB wrote:
> On 7/16/2011 2:43 AM, MikeP wrote:
>> Krice wrote:
>>> On 16 heinä, 12:29, "MikeP"<mp011...@some.org> wrote:
>>>> Wouldn't it be better
>>>> if a bool was a bool was a bool was a bool...?
>>>
>>> Yes, it's better. Don't mix bools and ints, they are different types.
>>
>> I was asking WHY they did that (mixed up bools and ints) in C++.
>>
>
> because C++ came directly from C, which generally didn't/doesn't have
> bool (a "_Bool" type was added in C99, but is not so often used).
>
> in C tradition, zero means false and non-zero means true, and C++ mostly
> just followed suit, making relatively few changes to the fundamental C
> core.

Except that in C++, the standard streams treat them differently. A 
non-zero integral input puts the stream into an error state suggesting 
this to be a failure condition. Anywhere else in C++ realms, a non-zero 
is true but with streams it is different. Not sure as to why this was 
designed so.

Thanks and regards,
Abhishek Padmanabh

[toc] | [prev] | [next] | [standalone]

#7909

On 7/16/2011 10:52 AM, Abhishek Padmanabh wrote:
> On 7/16/2011 10:54 AM, BGB wrote:
>> On 7/16/2011 2:43 AM, MikeP wrote:
>>> Krice wrote:
>>>> On 16 heinä, 12:29, "MikeP"<mp011...@some.org> wrote:
>>>>> Wouldn't it be better
>>>>> if a bool was a bool was a bool was a bool...?
>>>>
>>>> Yes, it's better. Don't mix bools and ints, they are different types.
>>>
>>> I was asking WHY they did that (mixed up bools and ints) in C++.
>>>
>>
>> because C++ came directly from C, which generally didn't/doesn't have
>> bool (a "_Bool" type was added in C99, but is not so often used).
>>
>> in C tradition, zero means false and non-zero means true, and C++ mostly
>> just followed suit, making relatively few changes to the fundamental C
>> core.
>
> Except that in C++, the standard streams treat them differently. A
> non-zero integral input puts the stream into an error state suggesting
> this to be a failure condition. Anywhere else in C++ realms, a non-zero
> is true but with streams it is different. Not sure as to why this was
> designed so.
>

it is not clear what value you are talking about here...

if it is an error status, well, this is not the same as a boolean 
true/false. traditionally, an error code of 0 means success.


also, if one has, say:
bool hasError;

well then, one can infer that the bool being true (non-zero, generally 
1) means it has an error status, so boolean true/false and 
success/failure are not necessarily related.

[toc] | [prev] | [next] | [standalone]

#7913

On 7/17/2011 7:03 AM, BGB wrote:
> On 7/16/2011 10:52 AM, Abhishek Padmanabh wrote:
>> On 7/16/2011 10:54 AM, BGB wrote:
>>> On 7/16/2011 2:43 AM, MikeP wrote:
>>>> Krice wrote:
>>>>> On 16 heinä, 12:29, "MikeP"<mp011...@some.org> wrote:
>>>>>> Wouldn't it be better
>>>>>> if a bool was a bool was a bool was a bool...?
>>>>>
>>>>> Yes, it's better. Don't mix bools and ints, they are different types.
>>>>
>>>> I was asking WHY they did that (mixed up bools and ints) in C++.
>>>>
>>>
>>> because C++ came directly from C, which generally didn't/doesn't have
>>> bool (a "_Bool" type was added in C99, but is not so often used).
>>>
>>> in C tradition, zero means false and non-zero means true, and C++ mostly
>>> just followed suit, making relatively few changes to the fundamental C
>>> core.
>>
>> Except that in C++, the standard streams treat them differently. A
>> non-zero integral input puts the stream into an error state suggesting
>> this to be a failure condition. Anywhere else in C++ realms, a non-zero
>> is true but with streams it is different. Not sure as to why this was
>> designed so.
>>
>
> it is not clear what value you are talking about here...
>

I should have said a non-zero integral value input other than 1. For 
example:

#include <iostream>
int main ()
{
   bool a=false;
   std::cout << "insert 0 or 1:"; //insert anything other than 0 or 1
   std::cin >> a;  //failbit gets set for cin to signify failure
   if (a==true)
   {
     std::cout << "a is true";
   }
   else
   {
     std::cout << "a is false";
   }
}

Any input value other than 0 or 1 will cause the streams failbit to be 
set. However, if I just assigned that value to the boolean, it works 
given the implicit conversion rules. Both are not exactly identical 
scenarios but it would have been nice if the streams worked with such 
inputs too.

[toc] | [prev] | [next] | [standalone]

#7917

On 7/17/2011 1:02 AM, Abhishek Padmanabh wrote:
> On 7/17/2011 7:03 AM, BGB wrote:
>> On 7/16/2011 10:52 AM, Abhishek Padmanabh wrote:
>>> On 7/16/2011 10:54 AM, BGB wrote:
>>>> On 7/16/2011 2:43 AM, MikeP wrote:
>>>>> Krice wrote:
>>>>>> On 16 heinä, 12:29, "MikeP"<mp011...@some.org> wrote:
>>>>>>> Wouldn't it be better
>>>>>>> if a bool was a bool was a bool was a bool...?
>>>>>>
>>>>>> Yes, it's better. Don't mix bools and ints, they are different types.
>>>>>
>>>>> I was asking WHY they did that (mixed up bools and ints) in C++.
>>>>>
>>>>
>>>> because C++ came directly from C, which generally didn't/doesn't have
>>>> bool (a "_Bool" type was added in C99, but is not so often used).
>>>>
>>>> in C tradition, zero means false and non-zero means true, and C++
>>>> mostly
>>>> just followed suit, making relatively few changes to the fundamental C
>>>> core.
>>>
>>> Except that in C++, the standard streams treat them differently. A
>>> non-zero integral input puts the stream into an error state suggesting
>>> this to be a failure condition. Anywhere else in C++ realms, a non-zero
>>> is true but with streams it is different. Not sure as to why this was
>>> designed so.
>>>
>>
>> it is not clear what value you are talking about here...
>>
>
> I should have said a non-zero integral value input other than 1. For
> example:
>
> #include <iostream>
> int main ()
> {
> bool a=false;
> std::cout << "insert 0 or 1:"; //insert anything other than 0 or 1
> std::cin >> a; //failbit gets set for cin to signify failure
> if (a==true)
> {
> std::cout << "a is true";
> }
> else
> {
> std::cout << "a is false";
> }
> }
>

the example above points out what was being talked about, but your 
wording was very non-obvious.


> Any input value other than 0 or 1 will cause the streams failbit to be
> set. However, if I just assigned that value to the boolean, it works
> given the implicit conversion rules. Both are not exactly identical
> scenarios but it would have been nice if the streams worked with such
> inputs too.


errm, this is a matter of input validation. in the case of a non-0/1 
answer, iostream just doesn't want to accept it (for whatever reason), 
although sanely it could have accepted other values and coerced them, or 
even accepted other bool-like tokens (yes/no, true/false, ...).

but, this is iostream-specific behavior.


personally though, I don't much use iostream (I more prefer stdio and 
doing parsing more manually instead).

[toc] | [prev] | [next] | [standalone]

#7901

On Sat, 16 Jul 2011 04:29:14 -0500, "MikeP" <mp011011@some.org> wrote:

>Why can bool types be implicitly converted to ints? Wouldn't it be better 
>if a bool was a bool was a bool was a bool...? The complementary question 
>is also a curiosity: why can an int be converted to a bool? I think the 
>answer to the last question has to do with "trueness" in C++ historically 
>meaning "not zero" instead of meaning "one". 


Why can shorts be implicitly converted to ints?  Or ints to longs?  Or
floats to doubles?  Or...?

There are languages which have no implicit conversions.  There's an
argument that it's safer, although it certainly leads to a lot of
extra typing.  But a number of implicit conversion ("promotions") have
always been part of C - the ones for bool are not really out of line
given the usual way truth has been defined in C.

[toc] | [prev] | [next] | [standalone]

#7904

Robert Wessel wrote:
> On Sat, 16 Jul 2011 04:29:14 -0500, "MikeP" <mp011011@some.org> wrote:
>
>> Why can bool types be implicitly converted to ints? Wouldn't it be
>> better if a bool was a bool was a bool was a bool...? The
>> complementary question is also a curiosity: why can an int be
>> converted to a bool? I think the answer to the last question has to
>> do with "trueness" in C++ historically meaning "not zero" instead of
>> meaning "one".
>
>
> Why can shorts be implicitly converted to ints?  Or ints to longs?  Or
> floats to doubles?  Or...?

Because the are numeric? (Now what do you think?).

>
> There are languages which have no implicit conversions.

The Haskell, Scheme, OCaml set, yes? Kinda makes me wanna cozy up to 
functional languages. (Not ironic that they are called FUNCTIONAL, eh?).

>  There's an
> argument that it's safer, although it certainly leads to a lot of
> extra typing.  But a number of implicit conversion ("promotions") have
> always been part of C - the ones for bool are not really out of line
> given the usual way truth has been defined in C. 

[toc] | [prev] | [next] | [standalone]

#7911

On Sun, 17 Jul 2011 00:02:02 -0500, "MikeP" <mp011011@some.org> wrote:

>Robert Wessel wrote:
>> On Sat, 16 Jul 2011 04:29:14 -0500, "MikeP" <mp011011@some.org> wrote:
>>
>>> Why can bool types be implicitly converted to ints? Wouldn't it be
>>> better if a bool was a bool was a bool was a bool...? The
>>> complementary question is also a curiosity: why can an int be
>>> converted to a bool? I think the answer to the last question has to
>>> do with "trueness" in C++ historically meaning "not zero" instead of
>>> meaning "one".
>>
>>
>> Why can shorts be implicitly converted to ints?  Or ints to longs?  Or
>> floats to doubles?  Or...?
>
>Because the are numeric? (Now what do you think?).


I think from a C perspective, bools are very close to numerics.  You
may think otherwise.

[toc] | [prev] | [next] | [standalone]

#7920

Robert Wessel wrote:
> On Sun, 17 Jul 2011 00:02:02 -0500, "MikeP" <mp011011@some.org> wrote:
>
>> Robert Wessel wrote:
>>> On Sat, 16 Jul 2011 04:29:14 -0500, "MikeP" <mp011011@some.org>
>>> wrote:
>>>
>>>> Why can bool types be implicitly converted to ints? Wouldn't it be
>>>> better if a bool was a bool was a bool was a bool...? The
>>>> complementary question is also a curiosity: why can an int be
>>>> converted to a bool? I think the answer to the last question has to
>>>> do with "trueness" in C++ historically meaning "not zero" instead
>>>> of meaning "one".
>>>
>>>
>>> Why can shorts be implicitly converted to ints?  Or ints to longs?
>>> Or floats to doubles?  Or...?
>>
>> Because the are numeric? (Now what do you think?).
>
>
> I think from a C perspective, bools are very close to numerics.  You
> may think otherwise.

I hate you. 

[toc] | [prev] | [next] | [standalone]

#7997

Robert Wessel wrote:
> On Sun, 17 Jul 2011 00:02:02 -0500, "MikeP" <mp011011@some.org> wrote:
>
>> Robert Wessel wrote:
>>> On Sat, 16 Jul 2011 04:29:14 -0500, "MikeP" <mp011011@some.org>
>>> wrote:
>>>
>>>> Why can bool types be implicitly converted to ints? Wouldn't it be
>>>> better if a bool was a bool was a bool was a bool...? The
>>>> complementary question is also a curiosity: why can an int be
>>>> converted to a bool? I think the answer to the last question has to
>>>> do with "trueness" in C++ historically meaning "not zero" instead
>>>> of meaning "one".
>>>
>>>
>>> Why can shorts be implicitly converted to ints?  Or ints to longs?
>>> Or floats to doubles?  Or...?
>>
>> Because the are numeric? (Now what do you think?).
>
>
> I think from a C perspective, bools are very close to numerics.  You
> may think otherwise.

Outside of the C perversion, in general they are logicals. A 2-state type 
does not seem very numeric to me. 

[toc] | [prev] | [next] | [standalone]

#8330

MikeP wrote:
> Robert Wessel wrote:
>> On Sat, 16 Jul 2011 04:29:14 -0500, "MikeP" <mp011011@some.org> wrote:
>>
>>> Why can bool types be implicitly converted to ints? 
  ...
>> There are languages which have no implicit conversions.
> 
> The Haskell, Scheme, OCaml set, yes?

For an example of a language without implicit conversions, from the same 
programming paradigm as C++ (imperative, procedural), take Ada.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#8357

HonestAbe wrote:
> Niklas Holsti wrote:
>> MikeP wrote:
>>> Robert Wessel wrote:
>>>> On Sat, 16 Jul 2011 04:29:14 -0500, "MikeP" <mp011011@some.org>
>>>> wrote:
>>>>> Why can bool types be implicitly converted to ints?
>>  ...
>>>> There are languages which have no implicit conversions.
>>> The Haskell, Scheme, OCaml set, yes?
>> For an example of a language without implicit conversions, from the
>> same programming paradigm as C++ (imperative, procedural), take Ada.
> 
> "Take Ada" and... what?

Did you have trouble with my grammar? MikeP was asking (indirectly, 
perhaps) for examples of languages without implicit conversions. So I 
said, "take Ada as an example". Clear now?

> Why don't YOU take Ada, and I'll take the hot chick!. :P

I already took Ada. Since about 1985 it still is the language that fits 
me best, thanks for asking.

I trust you and the hot chick are having a good time, too.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#8001

On Jul 16, 10:29 am, "MikeP" <mp011...@some.org> wrote:
> Why can bool types be implicitly converted to ints? Wouldn't it be better
> if a bool was a bool was a bool was a bool...? The complementary question
> is also a curiosity: why can an int be converted to a bool? I think the
> answer to the last question has to do with "trueness" in C++ historically
> meaning "not zero" instead of meaning "one".

The reasons are purely historical.  B only had a single type,
word, which was used for everything.  When used in a boolean
context, the word was interpreted as an int (even if it was in
fact a pointer or a floating point), and compared with 0.  When
C added types, the original motivation was to distinguish
between different sized values, and to allow operator
overloading (same operator for integral addition and floating
point addition).  Bool wasn't necessary for that, so it didn't
get added.  And C++ originally just adopted C's rules.  When
bool was added to C++, it was intentionally done in a way that
would allow the simplest conversions for the enormous number of
programs using typedef's and #define's to simulate bool's, and
in a way which wouldn't break existing code.  (IIRC, the original
proposal did recommend deprecating the conversions.  But that
somehow got lost in the final proposal.)

--
James Kanze

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web