Le 27 févr. 2012 à 02:40, Graham Cox a écrit :
On 27/02/2012, at 12:13 PM, William Squires wrote:
I prefer the if (self = [super init]) combined form, myself.
One potentially annoying thing about this form is that, if you compile with
plenty of warnings on, such as the possible
On 27 Feb 2012, at 03:51, Preston Sumner wrote:
On Feb 26, 2012, at 7:38 PM, Graham Cox wrote:
On 27/02/2012, at 1:27 PM, Karl Goiser wrote:
use double parentheses
Yes, but that's not what the poster was suggesting. I pointed out why that
form is bad.
This is a solution, but so
This is one of those things that comes from the C background - any non-zero
value is true; thus the two statements are equivalent. I prefer the if (self =
[super init]) combined form, myself.
On Feb 24, 2012, at 8:50 AM, Oleg Krupnov wrote:
An interesting question. The following samples are
On 27/02/2012, at 12:13 PM, William Squires wrote:
I prefer the if (self = [super init]) combined form, myself.
One potentially annoying thing about this form is that, if you compile with
plenty of warnings on, such as the possible unintended assignment warning (if
not, why not?) then this
Actually, I believe there's a specific build setting that special cases just
this construct; it seems to default to 'on' at least in Xcode 4.2 under SL, as
I never get the 'unintended assignment' warning, even though it does warn me in
other cases where I might type if (a = b) or some such.
If you use double parentheses, you won’t get the warning:
if ((self = [super init])) {
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at
I think you can turn it off, but I think you can also use double-()'s to
suppress it:
if ((self = [super init]))
On Feb 26, 2012, at 5:40 PM, Graham Cox wrote:
On 27/02/2012, at 12:13 PM, William Squires wrote:
I prefer the if (self = [super init]) combined form, myself.
One
On 27/02/2012, at 1:27 PM, Karl Goiser wrote:
use double parentheses
Yes, but that's not what the poster was suggesting. I pointed out why that form
is bad.
This is a solution, but so is Apple's recommended form.
--Graham
___
Cocoa-dev mailing
On Feb 26, 2012, at 7:38 PM, Graham Cox wrote:
On 27/02/2012, at 1:27 PM, Karl Goiser wrote:
use double parentheses
Yes, but that's not what the poster was suggesting. I pointed out why that
form is bad.
This is a solution, but so is Apple's recommended form.
--Graham
Out of
if(nil != (self = [super init]))
Myself I find it elegantly brief and imminently readable.
I don't mind it, but to me it begs the question of what it offers over:
self = [super init];
if (self) {
My rationale is, generally you avoid assignments within conditionals because
On Feb 24, 2012, at 1:08 PM, Nick Zitzmann wrote:
I also heard that generally speaking NULL is not necessarily always
equal to 0 on all architectures.
Thoughts?
Where in the world did you hear that? From the C99 standard, 6.3.2.3
paragraph 3:
An integer constant expression with the
On Feb 24, 2012, at 2:07 PM, Scott Ribe scott_r...@elevated-dev.com wrote:
On Feb 24, 2012, at 10:52 AM, Wade Tregaskis wrote:
Though technically speaking it's true, and is thus an argument for actually
using NULL rather than 0
No, it's not such an argument at all. The compiler
To me, it breaks one of my golden rules, and exposes one of the things I
dislike about C. Expressions, at least in my mind, should not involve state
change – that's what statements are for.
My rationale behind this is that it makes it easier to read expressions – you
get one more guarantee
On 24 Feb 2012, at 20:36, Sean McBride s...@rogue-research.com wrote:
On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said:
I don't believe this is the case. There can be funny issues with BOOL
types, such that BOOL == YES is an inadvisable construct, since your
BOOL could be an integer of
Not terribly helpful since the cocoa headers are what they are, but in other
codebases I sneak around issue this by setting up the defines:
#define FALSE 0
#define TRUE (!FALSE)
Then something like if (mybool == TRUE) acts as expected across all non-zero
values.
Also, IIRC, static analysis
On Feb 24, 2012, at 10:53 PM, Kyle Sluder wrote:
On Feb 24, 2012, at 2:07 PM, Scott Ribe scott_r...@elevated-dev.com wrote:
On Feb 24, 2012, at 10:52 AM, Wade Tregaskis wrote:
Though technically speaking it's true, and is thus an argument for actually
using NULL rather than 0
No, it's
On Feb 25, 2012, at 2:29 AM, David Mirabito wrote:
Not terribly helpful since the cocoa headers are what they are, but in other
codebases I sneak around issue this by setting up the defines:
#define FALSE 0
#define TRUE (!FALSE)
Then something like if (mybool == TRUE) acts as expected
On 25/02/2012, at 2:29 PM, Scott Ribe wrote:
On Feb 25, 2012, at 2:29 AM, David Mirabito wrote:
Not terribly helpful since the cocoa headers are what they are, but in other
codebases I sneak around issue this by setting up the defines:
#define FALSE 0
#define TRUE (!FALSE)
Then
On Feb 25, 2012, at 6:22 AM, Scott Ribe scott_r...@elevated-dev.com wrote:
I saw your citations. You're ignoring the Except as previously specified
clause at the beginning of the sentence you quote. Null pointers converted to
int become 0; other pointers are implementation defined.
Please
On Feb 25, 2012, at 8:23 AM, Kyle Sluder wrote:
And then show how that jives with footnote 56, which says that the intent of
the standard is that null pointers become whatever integer is most similar to
the bit pattern used for null pointers, which may or may not be the same as
that used
On Feb 25, 2012, at 7:26 AM, Scott Ribe scott_r...@elevated-dev.com wrote:
On Feb 25, 2012, at 8:23 AM, Kyle Sluder wrote:
And then show how that jives with footnote 56, which says that the intent of
the standard is that null pointers become whatever integer is most similar
to the bit
On Feb 25, 2012, at 7:38 AM, Kyle Sluder kyle.slu...@gmail.com wrote:
compared to an nether constant expression with the value 0
Integer, not nether. Silly autocorrect.
--Kyle Sluder
(Sent from my uPas)
___
Cocoa-dev mailing list
On Feb 25, 2012, at 8:38 AM, Kyle Sluder wrote:
Does Harbison Steele say that pointers converted to integer have the value
zero, or does it say that if(ptr) is identical to if(ptr != 0)?
It explicitly states that null pointers converted to int are 0, and that other
conversions are
On Feb 25, 2012, at 7:45 AM, Scott Ribe scott_r...@elevated-dev.com wrote:
On Feb 25, 2012, at 8:38 AM, Kyle Sluder wrote:
Does Harbison Steele say that pointers converted to integer have the value
zero, or does it say that if(ptr) is identical to if(ptr != 0)?
It explicitly states that
On Feb 25, 2012, at 7:56 AM, Kyle Sluder kyle.slu...@gmail.com wrote:
…converting a pointer to integer is not guaranteed to result in a
representation that fits in any size of integer…
You can use uintptr_t for such purposes, which is supposed to be defined in
stdint.h.
--
Gary L. Wade (Sent
On Feb 25, 2012, at 6:29 AM, Scott Ribe scott_r...@elevated-dev.com wrote:
(!0) evaluates to 1.
I've seen it evaluate to -1 in one compiler some time back when stored in a
signed integer bit field variable.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/
On 2/24/12, Sean McBride s...@rogue-research.com wrote:
On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said:
I don't believe this is the case. There can be funny issues with BOOL
types, such that BOOL == YES is an inadvisable construct, since your
BOOL could be an integer of any value.
An interesting question. The following samples are equivalent in terms
of compiled code, but which one is more correct from the language's
point of view?
self = [super init];
if (self)
{
}
return self;
self = [super init];
if (self != nil)
{
}
return self;
The Xcode samples promote the first
Really, this belongs in the Objective-C mailing list, but...
If the language provides a feature, then it is correct in terms of the
language.
That said, I always use the long form, just to be sure I'm always specifying a
boolean condition. This helps me when I'm combining or separating
On Feb 24, 2012, at 6:50 AM, Oleg Krupnov wrote:
So basically, nil is of type void*, so the expression self != nil
compares two pointers and the result is boolean, which is perfect
for testing in the if statement. But the self alone is of type
pointer and so when it is tested by the if
On 24 Feb 2012, at 8:50 AM, Oleg Krupnov wrote:
An interesting question. The following samples are equivalent in terms
of compiled code, but which one is more correct from the language's
point of view?
self = [super init];
if (self)
{
}
return self;
self = [super init];
if (self !=
On Feb 24, 2012, at 7:50 AM, Oleg Krupnov wrote:
An interesting question. The following samples are equivalent in terms
of compiled code, but which one is more correct from the language's
point of view?
self = [super init];
if (self)
{
}
return self;
self = [super init];
if (self !=
Neither is more correct.
The main distinction is whether you are happy with C's (very weak) type system
or not.
If you are satisfied that if simply checks if some integer typed value is equal
to 0 or not, and uses the first branch if it isn't, then the former is more
concise and better for
On Feb 24, 2012, at 7:50 AM, Oleg Krupnov wrote:
I also heard that generally speaking NULL is not necessarily always
equal to 0 on all architectures.
Thoughts?
Yeah, don't worry about it. The if(self) form is idiomatic C, by which I mean
it's the way that C code has been written since the
self = [super init];
if (self)
{
}
return self;
self = [super init];
if (self != nil)
{
}
return self;
The Xcode samples promote the first variant, but I'm wondering if the
second one is more correct?
No. The more common convention in (Apple's) ObjC is to use implicit boolean
I usually prefer the more explicit form (of any expression) because it more
obviously describes what is happening. That is your second example. However,
anyone who works with any variant of C quickly becomes comfortable with the
first form, so I consider it quite acceptable.
There is another
On Fri, Feb 24, 2012 at 6:50 AM, Oleg Krupnov oleg.krup...@gmail.com wrote:
An interesting question. The following samples are equivalent in terms
of compiled code, but which one is more correct from the language's
point of view?
self = [super init];
if (self)
{
}
return self;
self =
Also, this question is much more appropriate for the objc-language
list than it is for cocoa-dev.
--Kyle Sluder
On Fri, Feb 24, 2012 at 6:50 AM, Oleg Krupnov oleg.krup...@gmail.com wrote:
An interesting question. The following samples are equivalent in terms
of compiled code, but which one is
Yes, I'm aware that in practice it doesn't matter, but when I code, I have to
choose one or the other way, anyway. My current choice is (self != nil) for the
sake of explicitness.
Thanks everyone for an interesting discussion, especially Kyle for such an
exhaustive reference :)
P.S. Sorry
On Feb 24, 2012, at 7:50 AM, Oleg Krupnov wrote:
An interesting question. The following samples are equivalent in terms
of compiled code, but which one is more correct from the language's
point of view?
self = [super init];
if (self)
{
}
return self;
self = [super init];
if (self
And what does the list feel about the following form (which I think I picked up
from a Wil Shipley article):
if(nil != (self = [super init]))
Myself I find it elegantly brief and imminently readable.
Time Dwarf,
Roaring Guy
On 2012-02-24, at 9:30 AM, David Duncan david.dun...@apple.com
On Feb 24, 2012, at 6:50 AM, Oleg Krupnov oleg.krup...@gmail.com wrote:
I also heard that generally speaking NULL is not necessarily always
equal to 0 on all architectures.
In practice, NULL is always 0. Any exceptions were ancient historical oddities
that you can ignore.
In principle, the C
On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said:
I don't believe this is the case. There can be funny issues with BOOL
types, such that BOOL == YES is an inadvisable construct, since your
BOOL could be an integer of any value.
Indeed, and it's extremely frustrating. I encourage you to file
On Feb 24, 2012, at 10:36 AM, Keary Suska wrote:
I also heard that generally speaking NULL is not necessarily always
equal to 0 on all architectures.
I don't believe this is the case.
Actually it is--in fact there can even be multiple representations that are
null, but again the language
I also heard that generally speaking NULL is not necessarily always
equal to 0 on all architectures.
I don't believe this is the case. There can be funny issues with BOOL types,
such that BOOL == YES is an inadvisable construct, since your BOOL could be
an integer of any value.
In the
On 24 Feb 2012, at 9:52 am, Scott Ribe wrote:
Now there is one style that is worth defending, which is when comparing a
variable to a constant, put the constant first. Consider the following:
if(self == nil)...
if(self = nil)...
if(nil == self)...
if(nil = self)...
The 1st 3rd are
On Feb 24, 2012, at 2:47 PM, Ben Kennedy wrote:
Fortunately the compiler (nowadays) warns in these situations, and suggests
that one either fix the operator or enclose the expression in extra
parentheses to clarify the intent.
Sometimes. I've found that various warnings come go with Xcode
On Feb 24, 2012, at 10:52 AM, Wade Tregaskis wrote:
Though technically speaking it's true, and is thus an argument for actually
using NULL rather than 0
No, it's not such an argument at all. The compiler guarantees that null
pointers converted to int become 0, that constant 0 assigned to a
On Feb 24, 2012, at 12:47 PM, Kyle Sluder wrote:
But I'm not sure the integer conversion is necessarily relevant. The
semantics of the if statement are defined by §6.8.4.1 ¶2: the first
substatement is executed if the expression compares unequal to 0. It
is left unspecified if '0' is an
if(self == nil)...
if(self = nil)...
if(nil == self)...
if(nil = self)...
The 1st 3rd are the correct conditions, the 2nd 4th are typos. But the
2nd compiles and gives incorrect behavior, while the 4th fails to compile.
Of course if(self) is not subject to that kind of typo, but if
50 matches
Mail list logo
