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 expected,
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___
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 too
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
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 not.
Not
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
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 – it
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 same at all. One
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 guarantees
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 true.
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.
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
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 1999. Maybe
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 KR 1st edition ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
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
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())
{
if(
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 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 companies
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 in
-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.
...
I
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
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
On Sun, 31 Jul 2011 15:13:45 -0500, Gordon Apple said:
The following expression generates a warning message (32 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 isInUse =
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
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, welll,
On Mon, Aug 1, 2011 at 4:08 PM, Greg Parker gpar...@apple.com 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
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.com
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
Sorry, that should have been posted to Xcode.
On 7/31/11 3:13 PM, Gordon Apple g...@ed4u.com 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
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 isInUse =
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
31 matches
Mail list logo
