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
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 pos
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.
>
> --Grah
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
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.
>
>
> On
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 cocoa-dev-a
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.
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 thi
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 a
On 2/24/12, Sean McBride 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.
>
> Indeed, and it's ext
On Feb 25, 2012, at 6:29 AM, Scott Ribe 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/
___
C
On Feb 25, 2012, at 7:56 AM, Kyle Sluder 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 from my iPhone)
htt
On Feb 25, 2012, at 7:45 AM, Scott Ribe 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 null pointers conv
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 impleme
On Feb 25, 2012, at 7:38 AM, Kyle Sluder 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 (Cocoa-dev@lists.apple.com)
Please do
On Feb 25, 2012, at 7:26 AM, Scott Ribe 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 pattern used for null p
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 use
On Feb 25, 2012, at 6:22 AM, Scott Ribe 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 cite where the standard
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)
>
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 ex
On Feb 24, 2012, at 10:53 PM, Kyle Sluder wrote:
> On Feb 24, 2012, at 2:07 PM, Scott Ribe 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
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 24 Feb 2012, at 20:36, Sean McBride 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.
>
>
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 abo
On Feb 24, 2012, at 15:26 , Scott Ribe wrote:
> Thing is: if(foo) is equivalent to if(foo != 0), which I think results in 0
> being treated as a pointer, not the pointer being cast to int, anyway if
> if(foo) could fail, so could if(foo != 0)... Also I think "Except as
> previously specified...
On Feb 24, 2012, at 2:07 PM, Scott Ribe 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 guarantees that null
> point
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 expressi
>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 becau
> 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
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
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 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 Xc
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 & 3
>> 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.
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 la
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 fi
On Feb 24, 2012, at 6:50 AM, Oleg Krupnov 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 language says that NU
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 wrote:
> On Feb 24, 20
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];
>
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 fo
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 wrote:
> An interesting question. The following samples are equivalent in terms
> of compiled code, but which one is more correct from the
On Fri, Feb 24, 2012 at 6: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];
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 fo
> 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 implici
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 t
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 y
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];
>
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];
> i
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 b
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 multip
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 var
51 matches
Mail list logo
