Re: [LAD] Mixed boolean & numbers

[Will J Godfrey]

On Wed, 31 Aug 2016 21:28:45 -0400
David Robillard  wrote:

> On Sat, 2016-08-27 at 16:49 +0100, Will Godfrey wrote:
> > I'm finding quite a lot of occasions where variables defined as 'bool' are
> > sometimes being set with true or false and other times 0 or 1. On one 
> > occasion
> > there is something like x = n + {boolean variable}
> > 
> > This last one seems quite unsafe to me as I didn't think the actual value of
> > true and false was guaranteed.
> > 
> > Am I being overly cautious or should I change them all to one form or the 
> > other?  
> 
> This is fine.  The C/C++ standards guarantee that a bool, when converted
> to an integer, is 1 or 0 (the pedantically correct way of saying this
> depends on which standard/revision, but effectively that sums it up).
> 
> It's pretty convenient/elegant at times.  Personally, I exploit it when
> that's the case, but be more explicit if it has potential to be
> confusing.

Thanks again for the info.


-- 
It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixed boolean & numbers

[David Robillard]

On Sat, 2016-08-27 at 16:49 +0100, Will Godfrey wrote:
> I'm finding quite a lot of occasions where variables defined as 'bool' are
> sometimes being set with true or false and other times 0 or 1. On one occasion
> there is something like x = n + {boolean variable}
> 
> This last one seems quite unsafe to me as I didn't think the actual value of
> true and false was guaranteed.
> 
> Am I being overly cautious or should I change them all to one form or the 
> other?

This is fine.  The C/C++ standards guarantee that a bool, when converted
to an integer, is 1 or 0 (the pedantically correct way of saying this
depends on which standard/revision, but effectively that sums it up).

It's pretty convenient/elegant at times.  Personally, I exploit it when
that's the case, but be more explicit if it has potential to be
confusing.

-- 
dr

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixed boolean & numbers

[Will Godfrey]

On Sat, 27 Aug 2016 09:35:26 -0700 (PDT)
Len Ovens  wrote:

> On Sat, 27 Aug 2016, Will Godfrey wrote:
> 
> > I'm finding quite a lot of occasions where variables defined as 'bool' are
> > sometimes being set with true or false and other times 0 or 1. On one 
> > occasion
> > there is something like x = n + {boolean variable}
> >
> > This last one seems quite unsafe to me as I didn't think the actual value of
> > true and false was guaranteed.
> 
> I do not know if the compiler takes bool = int; and forces bool = 1 if int 
> = 5
> 
> According to:
> http://programmers.stackexchange.com/questions/145323/when-should-you-use-bools-in-c
> 
> bool a = FALSE;
> a = 5;
> 
> will give: error: no bool(const int&) available.
> 
> So, it should not be possible to set a bool to other than 0 or 1.
> bool = 1;
> is the same as bool = (bool) 1;
> I do not know what (bool) 5 or (bool) int would do :)
> bool = int; should fail to compile (assuming c++)
> bool == int may should be ok
> bool || int and bool && int are ok.
> 
> That is, 1 can be a bool value... 5 can not be a bool value and so should 
> fail.
> if(value) is different. internally I think you would find it looks like:
> if(value != 0)
> >
> > Am I being overly cautious or should I change them all to one form or the 
> > other?
> 
> So setting a bool to 1 or 0 is ok... but leaves the next person with less 
> of a clue what is happening. Changing the 1 and 0 to true and false would 
> make the code easier to follow.
> 
> x = n + {boolean variable}
> is a shortcut for
> if({boolean variable}) {
>   x = n + 1;
> } else {
>   x = n;
> }
> 
> Which helps someone reading the code to understand what is going on best?
> if the x = n + {boolean variable} is the next line after something that 
> tells the reader {boolean value} is a bool it is ok... but what if a patch 
> adds many lines in between. adding // y is a bool after might help.
> 
> So the code will work and probably not break. The code would be easier to 
> read using only true or false.
> 

Thanks Len,

Pretty much confirms what I thought. I think I'll correct those as I work on
associated bits of code, but change the addition one straight away. It's not
time critical, and I'm sure the compiler will optimise it anyway.

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixed boolean & numbers

[Len Ovens]

On Sat, 27 Aug 2016, Will Godfrey wrote:


I'm finding quite a lot of occasions where variables defined as 'bool' are
sometimes being set with true or false and other times 0 or 1. On one occasion
there is something like x = n + {boolean variable}

This last one seems quite unsafe to me as I didn't think the actual value of
true and false was guaranteed.


I do not know if the compiler takes bool = int; and forces bool = 1 if int 
= 5


According to:
http://programmers.stackexchange.com/questions/145323/when-should-you-use-bools-in-c

bool a = FALSE;
a = 5;

will give: error: no bool(const int&) available.

So, it should not be possible to set a bool to other than 0 or 1.
bool = 1;
is the same as bool = (bool) 1;
I do not know what (bool) 5 or (bool) int would do :)
bool = int; should fail to compile (assuming c++)
bool == int may should be ok
bool || int and bool && int are ok.

That is, 1 can be a bool value... 5 can not be a bool value and so should 
fail.

if(value) is different. internally I think you would find it looks like:
if(value != 0)


Am I being overly cautious or should I change them all to one form or the other?


So setting a bool to 1 or 0 is ok... but leaves the next person with less 
of a clue what is happening. Changing the 1 and 0 to true and false would 
make the code easier to follow.


x = n + {boolean variable}
is a shortcut for
if({boolean variable}) {
x = n + 1;
} else {
x = n;
}

Which helps someone reading the code to understand what is going on best?
if the x = n + {boolean variable} is the next line after something that 
tells the reader {boolean value} is a bool it is ok... but what if a patch 
adds many lines in between. adding // y is a bool after might help.


So the code will work and probably not break. The code would be easier to 
read using only true or false.



--
Len Ovens
www.ovenwerks.net

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Mixed boolean & numbers

[Will Godfrey]

I'm finding quite a lot of occasions where variables defined as 'bool' are
sometimes being set with true or false and other times 0 or 1. On one occasion
there is something like x = n + {boolean variable}

This last one seems quite unsafe to me as I didn't think the actual value of
true and false was guaranteed.

Am I being overly cautious or should I change them all to one form or the other?

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev