At the risk of offending contributors to this list, whose knowledge and
helpfulness I greatly respect, may I suggest that this thread has gone on long
enough and that competing opinions on this topic would be better aired on some
other list?
Boyd___
>> One important difference for instance is that if you write if (a() &
>> b()), both a() and b() will always be executed, while if you write if
>> (a() && b()), b() will be executed only if a() is true.
>
>
> The C language doesn't make any guarantees about that. While this
> optimisation is to be
On Aug 3, 2011, at 11:20 PM, Graham Cox wrote:
> On 04/08/2011, at 1:17 PM, Preston Sumner wrote:
>
>> I find short-circuit evaluation easier to read and much more concise, and,
>> of course, it's always nice to avoid unnecessary levels of nesting.
>
>
> I wouldn't necessarily disagree, but com
On 04/08/2011, at 1:17 PM, Preston Sumner wrote:
> I find short-circuit evaluation easier to read and much more concise, and, of
> course, it's always nice to avoid unnecessary levels of nesting.
I wouldn't necessarily disagree, but companies often have their own coding
standards that forbid
On Aug 3, 2011, at 8:10 PM, Andy Lee wrote:
> On Aug 3, 2011, at 9:51 PM, Graham Cox wrote:
>> I think the point they wanted to get across was that they didn't want to see
>> code like this:
>>
>> if( someFunction() && someOtherFunction()){ ... }
>>
>> instead of:
>>
>> if( someFunction())
>>
On Aug 3, 2011, at 9:51 PM, Graham Cox wrote:
> I think the point they wanted to get across was that they didn't want to see
> code like this:
>
> if( someFunction() && someOtherFunction()){ ... }
>
> instead of:
>
> if( someFunction())
> {
>if( someOtherFunction())
>{
>
>
On 04/08/2011, at 11:36 AM, glenn andreas wrote:
> More likely the somebody that interviewed you didn't have it correct in the
> first place, scarring you for life...
Well, that part's true :)
I seem to recall I failed that question, the only one I did. So I got the
lecture and never questio
On Aug 3, 2011, at 7:27 PM, Graham Cox wrote:
> In my defence, I saw this in a job interview but it was prior to 1999. Maybe
> C99 tightened up on something that was previously vague.
Nope, been that way since K&R 1st edition ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-d
On Aug 3, 2011, at 8:27 PM, Graham Cox wrote:
>
> On 04/08/2011, at 11:19 AM, Greg Parker wrote:
>
>>> This is a classic question for coding job interviews.
>>
>> Incorrect.
>
>
> Ah well, I guess I didn't get the job :)
>
> In my defence, I saw this in a job interview but it was prior to 1
The C99 spec I can find on the net has 6.5.13 (3) and (4).
3. The && operator shall yield 1 if both of it's operands compare unequal to 0;
otherwise it yields 0. The result has type int.
4. Unlike the bitwise binary & operator, the && operator guarantees
left-to-right evaluation; there is a s
On 04/08/2011, at 11:19 AM, Greg Parker wrote:
>> This is a classic question for coding job interviews.
>
> Incorrect.
Ah well, I guess I didn't get the job :)
In my defence, I saw this in a job interview but it was prior to 1999. Maybe
C99 tightened up on something that was previously vague
On Aug 3, 2011, at 5:56 PM, Graham Cox wrote:
> On 04/08/2011, at 1:52 AM, Jean-Daniel Dupas wrote:
>> One important difference for instance is that if you write if (a() & b()),
>> both a() and b() will always be executed, while if you write if (a() &&
>> b()), b() will be executed only if a() is
On 04/08/2011, at 1:52 AM, Jean-Daniel Dupas wrote:
> One important difference for instance is that if you write if (a() & b()),
> both a() and b() will always be executed, while if you write if (a() && b()),
> b() will be executed only if a() is true.
The C language doesn't make any guarante
Le 3 août 2011 à 16:40, Thomas Davie a écrit :
>
> On 3 Aug 2011, at 15:15, Scott Ribe wrote:
>
>> On Aug 3, 2011, at 7:54 AM, Thomas Davie wrote:
>>
>>> Not really – both C ands are the same and… they're just operating on
>>> different representations of booleans.
>>
>> No, they're not the
On 3 Aug 2011, at 15:15, Scott Ribe wrote:
> On Aug 3, 2011, at 7:54 AM, Thomas Davie wrote:
>
>> Not really – both C ands are the same and… they're just operating on
>> different representations of booleans.
>
> No, they're not the same at all. One is a bitwise operation on binary ints.
Yes
On Aug 3, 2011, at 7:54 AM, Thomas Davie wrote:
> Not really – both C ands are the same and… they're just operating on
> different representations of booleans.
No, they're not the same at all. One is a bitwise operation on binary ints.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.eleva
On 3 Aug 2011, at 14:29, Scott Ribe wrote:
> On Aug 3, 2011, at 1:53 AM, Dale Miller wrote:
>
>> A decent language (IMHO) would not confuse things with two different "and's".
>
> Well, there *are* two different and's, regardless of whether your favored
> languages allow you access to both or n
On Aug 3, 2011, at 1:53 AM, Dale Miller wrote:
> A decent language (IMHO) would not confuse things with two different "and's".
Well, there *are* two different and's, regardless of whether your favored
languages allow you access to both or not.
--
Scott Ribe
scott_r...@elevated-dev.com
http://w
You are correct. I get that wrong a lot. But that reinforces my point.
A decent language (IMHO) would not confuse things with two different
"and's". And my typo "'1001'" for "OX1001" probably was a Freudian
slip because of my fervent dislike of C's syntax for hex numbers. Or
maybe it was to
On Aug 2, 2011, at 7:57 PM, Dale Miller wrote:
> It is disconcerting that if A = 0x'0110' and B = '1001' then A & B returns
> true but A && B returns 0, so "if (A && B)' is executed, the 'true' leg is
> not taken
Don’t you have that backwards? Assuming B was supposed to be hex, i.e. 0x1001,
th
Conrad Shultz notified me that I had misinterpreted Greg Parker's
post. I will recant my accusation of hubris and apologize.
Dale Miller
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/11 5:57 PM, Dale Miller wrote:
> Greg Parker wrote: "A warning on '==' inside of 'if' is ridiculous.
> '==' is comparison for equality. "=' is assignment. Anyone who can't
> at least keep these two straight shouldn't be doing programming."
...
>
Greg Parker wrote: "A warning on '==' inside of 'if' is ridiculous.
'==' is comparison for equality. "=' is assignment. Anyone who can't
at least keep these two straight shouldn't be doing programming."
I'm glad that my bosses failed to discover my incompetence in my
40+years of programming i
On Aug 1, 2011, at 2:36 PM, Jeffrey Walton wrote:
> I wish I had a dollar for every time I lazy fingered `=` rather than
> `==`. And another buck for each time the compiler caught it (I use
> `-Wall` -Wextra` and firends).
Well, firend, I believe you ;-)
--
Scott Ribe
scott_r...@elevated-dev.co
On Mon, Aug 1, 2011 at 4:08 PM, Greg Parker wrote:
>
> On Aug 1, 2011, at 8:47 AM, Gordon Apple wrote:
>
>> It’s not that I object to anyone doing it, if that makes them more
>> comfortable, but a warning on ““&&” inside of “||”” is ridiculous. Everyone
>> knows that multiplication takes preceden
On Aug 1, 2011, at 8:47 AM, Gordon Apple wrote:
> It’s not that I object to anyone doing it, if that makes them more
> comfortable, but a warning on ““&&” inside of “||”” is ridiculous. Everyone
> knows that multiplication takes precedence over addition. “&&” is a
> multiplication. “||” is, we
If this warning bother you, just disable it.
clang is smart enough to tell you what flag you have to turn off in the warning
message.
For instance, just add -Wno-constant-logical-operand in your other warning
flags.
Le 1 août 2011 à 17:47, Gordon Apple a écrit :
> It’s not that I object to a
On Sun, 31 Jul 2011 15:13:45 -0500, Gordon Apple said:
>The following expression generates a warning message (3&&2 within 3||2) and
>says to include the 3anded2 expression in parens. Anybody who understands
>basic boolean operator precedence knows this is unnecessary. Bug report?
>
>BOOL isI
It¹s not that I object to anyone doing it, if that makes them more
comfortable, but a warning on ³³&&² inside of ³||²² is ridiculous. Everyone
knows that multiplication takes precedence over addition. ³&&² is a
multiplication. ³||² is, welll, almost an addition. (Exor is addition in a
mod 2 sys
On 01/08/2011, at 6:13 AM, Gordon Apple wrote:
> Anybody who understands
> basic boolean operator precedence knows this is unnecessary.
True, but who does? I mean, sure, if everyone who ever sees your source has
that fully committed to heart, you're golden. Otherwise, what's the harm of a
few
On Jul 31, 2011, at 1:13 PM, Gordon Apple wrote:
> The following expression generates a warning message (“&&” within “||”) and
> says to include the “anded” expression in parens. Anybody who understands
> basic boolean operator precedence knows this is unnecessary. Bug report?
>
>BOOL isI
Sorry, that should have been posted to Xcode.
On 7/31/11 3:13 PM, "Gordon Apple" wrote:
> The following expression generates a warning message (³&&² within ³||²) and
> says to include the ³anded² expression in parens. Anybody who understands
> basic boolean operator precedence knows this is unn
The following expression generates a warning message (³&&² within ³||²) and
says to include the ³anded² expression in parens. Anybody who understands
basic boolean operator precedence knows this is unnecessary. Bug report?
BOOL isInUse = [super mediaIsInUse];
isInUse = isInUse || [self v
33 matches
Mail list logo
