[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?)
From: |
Kazunobu Kuriyama |
Subject: |
Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?) |
Date: |
Mon, 09 Feb 2004 08:59:16 +0900 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 |
David Ayers wrote:
<snip>
I don't think we are in disagreement. My point is, in C truth semantics:
Yes, I am not against your proposal itself, and I think I understand
your point.
int i = 256;
if (i)
will be evaluted as true. But
if ([[NSNumber numberWithBool: i] boolValue])
will return the 'NO' BOOL instance and be evaluated as false.
I agree the result appears counter-intuitive, and that in many cases, it
may differ from
what we (carelessly) expect. But whatever our intention may be, the
higher bits of the
variable i are to be truncated because this is what the C language
specification promises
when an interger variable is converted into a one having a narrower bit
pattern. No one
is blamed for this.
Perhaps, we are inadvertently influenced by the word 'BOOL'. For
example, if I wrote
void func(unsigned char c)
{
if (c) printf("YES");
else printf("NO");
}
int main(void)
{
int i;
func(i = 256)
return 0;
}
and posted somewhere, writing 'That non-zero is true is false', then you
would definitely
laugh at me, ignoring the post, or reply to me, 'Why don't you read your
C book again?' if
you felt a pity on me.
On the other hand, what if I replaced void func(unsigned char c) with
void func(BOOL c)?
In this case, someone would be likely to track down the source of the
problem in favor of me.
And another thread similar to those we have recent days begins...
You can't rely on the C truth value (i.e. rely on the "true" value or
256) to be passed through the method invocation which converts the
integer to unsgnied char in this case '0' and expect to have get the
'YES' BOOL value as the parameter in the implementation of
+numberWithBool.
If I'm allowed to paraphrase your intention into something else, I'd say:
You can rely on the C truth value, BUT you must be careful when you use
a method/function invocation
involving one or more BOOL variables or a cast to BOOL. In ObjC, BOOL
is usually defined to be a shorter
integer type, and hence the integer promotion/conversion rules of C also
applies to it without any exception.
Therefore, when usign BOOL, you should be careful so that no unexpected
promotion/conversion will happen.
If your argument made clear the distinction between the C truth value
and the integer promotion/conversion,
I would never complain. I think these two are completely different
issues and hence believe we need
some argument on this to establish a firm foundation for the new coding
standard.
In fact, your propose looks fine to me, but I couldn't understand the
rationale. If you could make your
argument clear in terms of the point above, it would make the argument
stronger enough shut me up. ;-)
IOW: C "truths" (i.e. C truth semantice) aren't implicitly converted
to BOOL YES/NO. The conversion must be made explict.
I can't be against this! :-)
Cheers,
Kazunobu Kuriyama
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), (continued)
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), Kazunobu Kuriyama, 2004/02/09
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), Pascal J . Bourguignon, 2004/02/09
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), Kazunobu Kuriyama, 2004/02/10
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), David Ayers, 2004/02/10
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), Alexander Malmberg, 2004/02/10
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), Nicola Pero, 2004/02/10
- Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?),
Kazunobu Kuriyama <=
Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?), Alexander Malmberg, 2004/02/10