Re: [Obj-C] if (self) vs. if (self != nil)

[Citizen]

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 is Apple's recommended form.
>> 
>> --Graham
> 
> Out of curiosity, where does Apple recommend a particular form? Examples in 
> the online documentation are inconsistent in this regard.
> 
> Preston

The code snippet "Objective-C init Method" in Xcode takes this form.

i.e. 

- (id)init
{
self = [super init];
if (self) {
<#initializations#>
}
return self;
}

Dave
--
David Kennedy (http://www.zenopolis.com)

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Jean-Daniel Dupas]

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 unintended assignment warning (if 
> not, why not?) then this flags a warning.

clang knows about this special usage, and does not warn if you don't ask it to 
be to much pedantic.

Using the 2 following flags, it will warns about assignment used as condition, 
but not for if (self = [super init])

-Wparentheses -Wno-idiomatic-parentheses


-- Jean-Daniel





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Preston Sumner]

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 curiosity, where does Apple recommend a particular form? Examples in the 
online documentation are inconsistent in this regard.

Preston


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Graham Cox]

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 list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Eeyore]

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 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 flags a warning.
> 
> Apple recommend:
> 
> self = [super init];
> if( self )
> {
> ...
> }
> 
> 
> Anyway, this seems to be one of those tiny trivial issues that people seem to 
> get very religious about. It takes a second to type in any form, so what's 
> the big deal?
> 
> --Graham
> 
> 
> ___
> 
> 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-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
> 
> This email sent to eey...@monsterworks.com
> 


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Karl Goiser]

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[William Squires]

  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. IIRC, it's near the 
bottom of the compiler warnings that you can check off, but it's getting late 
at night...

On Feb 26, 2012, at 7: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 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 flags a warning.
> 
> Apple recommend:
> 
> self = [super init];
> if( self )
> {
> ...
> }
> 
> 
> Anyway, this seems to be one of those tiny trivial issues that people seem to 
> get very religious about. It takes a second to type in any form, so what's 
> the big deal?
> 
> --Graham
> 
> 

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Graham Cox]

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 flags a warning.

Apple recommend:

self = [super init];
if( self )
{
...
}


Anyway, this seems to be one of those tiny trivial issues that people seem to 
get very religious about. It takes a second to type in any form, so what's the 
big deal?

--Graham


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[William Squires]

  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 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 variant, but I'm wondering if the
> second one is more correct?
> 
> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)
> 
> 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" statement, it's
> implicitly cast to the type "boolean".
> 
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?
> ___
> 
> 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-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/wsquires%40satx.rr.com
> 
> This email sent to wsqui...@satx.rr.com


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Eric Wing]

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 extremely frustrating.  I encourage you to file bugs on
> this, or maybe add a comment here:
>
> 
>

Small tangent, but I think it's unlikely that Apple will change the
definition of BOOL of signed char to C99 _Bool. They already missed
ripe opportunities to do this with x86_64, iOS armv6 and armv7.
Perhaps the new enhancement request we should be filing is to
encourage the use of _Bool in all new APIs moving forward, especially
in new frameworks. (It's not completely unprecedented; I've seen some
other bool types used in the other Apple frameworks, plus we had that
whole int->NSInteger change not too long ago.)

-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Gary L. Wade]

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/

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Gary L. Wade]

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)
http://www.garywade.com/

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

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 converted to int are 0, and that 
> other conversions are implementation-defined but round-trip conversions 
> through a large-enough int type produce the original pointer.

Yeah, that's all kinds of wrong. As the standard also explicitly states, 
converting a pointer to integer is not guaranteed to result in a representation 
that fits in any size of integer, and it might be a trap representation. The 
conversion from integer to pointer is similarly implementation-defined. The 
only round-trip guaranteed by the standard is pointer-type to pointer-type, and 
then only if the pointer value is correctly aligned for the second pointee 
type, or the second pointer type is pointer-to-void.

> I have a suspicion that this is a normalization in behavior introduced in the 
> standardization process--note that I still have K&R 2nd edition here, and as 
> far as I can tell it simply does not specify what happens when a null pointer 
> is converted to int.

K&R 2nd Ed. was updated for C89, I believe. But regardless, K&R is notoriously 
light on specifics like this. Which is great when you're teaching a language, 
but not nearly as great when you're implementing a compiler that intends to 
support most of the code in the modern world.

--Kyle Sluder
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 implementation-defined but round-trip conversions through a 
large-enough int type produce the original pointer.

I have a suspicion that this is a normalization in behavior introduced in the 
standardization process--note that I still have K&R 2nd edition here, and as 
far as I can tell it simply does not specify what happens when a null pointer 
is converted to int.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

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 not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

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 pointers, which may or may not be the same 
>> as that used for integer zero depending on the platform.
> 
> Hmm. So Harbison & Steele (5th Edition) is wrong??? That's a surprise to me.

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)?

The first is an error. That is plain black and white in the standard. The 
second is quite possible, even likely. But because the standard just says 
"compared to 0" rather than "compared to an nether constant expression with the 
value 0," I don't know if it's guaranteed by the standard.

--Kyle Sluder
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 for integer zero depending on the platform.

Hmm. So Harbison & Steele (5th Edition) is wrong??? That's a surprise to me.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

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 says null pointers become zero when converted to 
integer.

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 for integer zero depending on the platform.

--Kyle Sluder
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[David Mirabito]

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 something like "if (mybool == TRUE)" acts as expected across all 
>> non-zero values. 
> 
> (!0) evaluates to 1.

Ha! Well there you go. I guess I just  saw that and accepted that it did what I 
looked like it was trying to do. Thanks for the correction.
That's my learned item for today, and sorry for the misinformation.

-David


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 across all 
> non-zero values. 

(!0) evaluates to 1.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 argument at all. The compiler guarantees that null 
>> pointers converted to int become 0,
> 
> No it very much doesn't. See my citations.

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.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[David Mirabito]

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 tools can enforce all boolean expressions in your 
code is a bolean logical operator or resolves to a 'typedef int mybool_t', but 
I'm less than convinced of the usefulness of this.

-DavidM


On 24/02/2012, at 8:36 PM, 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 extremely frustrating.  I encourage you to file bugs on 
> this, or maybe add a comment here:
> 
> 
> 
> -- 
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com 
> Mac Software Developer  Montréal, Québec, Canada
> 
> 
> 
> ___
> 
> 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-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.mirabito%40gmail.com
> 
> This email sent to david.mirab...@gmail.com


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[James Montgomerie]

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.
> 
> Indeed, and it's extremely frustrating.  I encourage you to file bugs on 
> this, or maybe add a comment here:
> 
> 

Danger!  The code in that bug report is unsafe in another unintended manner too.

BOOL isOK = someBitField & someFlag;

Is equivalent to

signed char isOK = (signed char)(someBitField & someFlag);

If someFlag is > 256, the bit that's left set after the '&' is executed will be 
truncated off by the assign converting down to 8 bits.

It's safer to do:
BOOL isOK = (someBitField & someFlag) == someFlag;

Or simply our controversial friend:
if(someBitField & someFlag);

Although I'd do:
if((someBitField & someFlag) == someFlag)

If only to silence compiler warnings about the naked single '&' in the if.

Slight tangent: I find the safest way, always, to approach 'if' is not to 
pretend that it's doing anything other than checking for non-zero values.  Once 
you accept that, lots of 'what's clearer' questions go away, because neither 
way is 'clearer', they're just more or less verbose.

Jamie.

[Apologies for formatting, edited on my phone.]
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Thomas Davie]

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 about what they're doing – they're computing a value, 
not changing some state behind your back.

This has a few implications for how I write code:
• I don't use the increment/decrement operators in expressions.
• I don't use the result value of assignments within expressions.
• Functions I try to keep as much as possible mathematical functions – they 
don't change state, they just return the result of a computation.
• If I need to return something from a subroutine that does change state, I 
tend to use a pointer argument rather than the result.

More specifically
• I don't use assignments in an if's condition, as below.

Bob
if (*ra4 != 0xffc78948) { return false; }

On 25 Feb 2012, at 01:12, Wade Tregaskis wrote:

>>   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 
> it's just plain awkward.  The if (self = [super init]) pattern is a rare 
> exception, that is justified purely by convention at this point.  If you're 
> going to break that convention, and increase the verbosity to boot, you 
> should probably just revert to fundamentals - i.e. treat it like any other 
> assignment and test.
> ___
> 
> 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-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/tom.davie%40gmail.com
> 
> This email sent to tom.da...@gmail.com

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Quincey Morris]

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..." covers the case that NULL pointers convert to int 
> 0...

The following two source code patterns are *exactly* identical to the C 
compiler, *regardless of the type of 'foo'*:

1. if (foo)
2. if (foo != 0)

Additionally, if 'foo' is any kind of pointer, then a third pattern is 
*exactly* identical to the first two:

3. if (foo != (void*) 0)

In Obj-C, the following are *exactly* identical to the third one (again, 
assuming 'foo' is a pointer):

4. if (foo != nil)
5. if (foo != NULL)

Thus, there's absolutely no technical reason not to use all 5 of these 
interchangeably for pointers. It's just a question of coding preference 
(including putting the constant on the left of the operator, which was 
discussed earlier in the thread, making a total of 9 equivalent coding 
patterns).

These equivalences [under the restrictions stated above] have *nothing* to do 
with the internal bit-pattern representation of a null pointer. There are *no* 
implementation dependencies in any of them, assuming a compliant C compiler 
like GCC or clang.

The *only* place where the internal bit-pattern matters, and where there might 
be implementation dependent behavior, is source code where a pointer 
sub-expression is mixed with a non-constant-evaluating-to-zero arithmetic 
sub-expression. So all of this angst is wasted effort. :)


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

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 
> pointers converted to int become 0,

No it very much doesn't. See my citations.

> that constant 0 assigned to a pointer makes it null,

This is true, but emphasis on the "constant." Assigning a non-constant integer 
expression to a pointer is implementation-defined, regardless of the value of 
the integer expression.

> and that null pointer compared to 0 is true

Again, this is dependent on context. Hence the doubt I expressed in my initial 
post. There is no direct comparison defined between pointer types and integers.

--Kyle Sluder
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 value 0, or such an expression cast 
> to type void *, is called a null pointer constant. If a null pointer constant 
> is converted to a pointer type, the resulting pointer, called a null pointer, 
> is guaranteed to compare unequal to a pointer to any object or function."
> 
> I suppose some compilers can ignore the standard and do their own thing, but 
> the compilers that come with Xcode are pretty good with standards compliance.

People just get confused by the point that the "null" or "illegal" pointer 
value is not all 0 bits on all architectures, but C makes reasonable efforts to 
treat NULL pointers and 0 as equivalent, regardless of what the underlying 
value might be, and this equivalence is transparent in most common cases. The 
word "null" is overloaded, so some people read the warning about the underlying 
bit representation of a null pointer, and confuse that with the representation 
at the source code level. 

The only places where they're not completely equivalent (in other words not 
equivalent on weird old architectures) have to do with things like 
converting/comparing non-constant integers to pointers, where a 0 becomes all 
0s regardless of what the null pointer is (which cases are the reason the 
warning about non-0 null pointers cannot be removed)... Basically, mixing 
pointers and constant integer 0 expressions to represent NULL works in all 
expressions on all architectures for all time (ahem, assuming you declare 
functions new style--if you pass an integer constant to a function that takes a 
pointer but does not have a declaration visible, on an architecture where where 
an int is smaller than the pointer, well you deserve what you get for turning 
off or ignoring compiler warnings in order to use an ancient obsolete style 
without understanding how to use that style).

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Wade Tregaskis]

>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 
it's just plain awkward.  The if (self = [super init]) pattern is a rare 
exception, that is justified purely by convention at this point.  If you're 
going to break that convention, and increase the verbosity to boot, you should 
probably just revert to fundamentals - i.e. treat it like any other assignment 
and test.
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Wade Tregaskis]

> 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 you're going 
> to insist on the verbose version, you might as well use if(nil == self).

Scott makes an excellent point.  I just want to emphasise it by saying how 
useful that has been to me over the years - countless bugs killed at birth.

I will admit it took me a while to get used to it, but the sooner you stop 
thinking about it the sooner it's natural.  You may run into people who dislike 
it on religious grounds, however.  For example, Google's internal style rules 
forbid it.  Try to make sure you're paid by bug count, if you find yourself in 
that situation. ;)
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 integer constant expression or an
> arithmetic expression with an integer value of zero. If the former,
> then the pointer is compared against the null pointer constant per
> §6.3.2.3 ¶4. If the latter, the pointer is converted to integer per
> implementation-defined behavior and the comparison is performed, which
> might itself result in undefined behavior per §6.5 ¶5 since the
> conversion is not guaranteed to produce a value within range of any
> integer type.

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..." covers the case that NULL pointers convert to int 0...


-- 
Scott Ribe
scott_ribe@elevated-dev.comhttp://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 pointer makes 
it null, and that null pointer compared to 0 is true--regardless of whether the 
underlying hardware/OS representation of a null pointer is all 0 bits or not.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 versions, 
without my changing project settings.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Ben Kennedy]

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 the correct conditions, the 2nd & 4th are typos. But the 
> 2nd compiles and gives incorrect behavior, while the 4th fails to compile.

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.  Personally I enjoy the latter.

b

--
Ben Kennedy, chief magician
Zygoat Creative Technical Services
http://www.zygoat.ca


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Marco S Hyman]

>> 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 C language an integral constant expression with the value 0 will always
translate to a null pointer.  The actual representation of a null pointer in
memory may not be 0.   Different pointer types may have different internal
values.   The compiler will know how to translate "0" to the appropriate value
IF it knows the value is being used as a pointer.

See http://c-faq.com/null/index.html for lots more on the subject.  It explains
thing like why func(x, 0) may not generate the same code as func(x, (char*) 0).

Marc
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 is specified to take care of making NULL pointers 
equivalent to 0 for comparing pointers to 0 and assigning constant 0 to 
pointers. It's not something most of us need to worry about: obscure embedded 
stuff, ancient segmented architectures, different size pointers to different 
data types, and other such madness.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Sean McBride]

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 bugs on this, 
or maybe add a comment here:



-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Greg Parker]

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 NULL must behave as if it were zero, but 
that the bit pattern of a null pointer in memory is not necessarily zero.

http://c-faq.com/null/machnon0.html
http://c-faq.com/null/varieties.html
http://c-faq.com/null/machexamp.html


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Erik Stainsby]

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, 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" statement, it's
>> implicitly cast to the type "boolean".
> 
> In C any non-zero value is 'true', as such if (self) vs if (self != nil) is a 
> pure stylistic choice, neither is more correct than the other in terms of the 
> language itself.
> --
> David Duncan
> 
> 
> ___
> 
> 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-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/erik.stainsby%40roaringsky.ca
> 
> This email sent to erik.stain...@roaringsky.ca

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Nick Zitzmann]

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 != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?

It isn't. Both are valid methods of checking to see if some object is non-zero.

> 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 value 0, or such an expression cast to 
type void *, is called a null pointer constant. If a null pointer constant is 
converted to a pointer type, the resulting pointer, called a null pointer, is 
guaranteed to compare unequal to a pointer to any object or function."

I suppose some compilers can ignore the standard and do their own thing, but 
the compilers that come with Xcode are pretty good with standards compliance.

Nick Zitzmann



___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Oleg Krupnov]

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 for posting the question into the wrong list. I'm a bit shaky in the 
classification of apple lists.



On Friday, February 24, 2012 at 9:47 PM, Kyle Sluder wrote:

> On Fri, Feb 24, 2012 at 6:50 AM, Oleg Krupnov  (mailto: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 = [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?
> >  
> > The "nil" is defined as follows (jumped to definition)
> >  
> > #define nil NULL
> > #define NULL ((void*)0)
> >  
> > 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" statement, it's
> > implicitly cast to the type "boolean".
> >  
> > I also heard that generally speaking NULL is not necessarily always
> > equal to 0 on all architectures.
> >  
>  
>  
> §6.3.2.3 ¶3 defines the null pointer constant as "an integer constant
> expression with the value 0, or such an expression cast to type void
> *". A null pointer is one that has been assigned the value of the null
> pointer constant, or has been assigned the value of another null
> pointer.
>  
> But you are correct that conversion of a null pointer to integer is
> NOT defined to compare equal to an integer expression with a value of
> zero. §6.3.2.3 ¶6 makes that clear: "Any pointer type may be converted
> to an integer type. Except as previously specified, the result is
> implementation-defined." However, footnote 56 states that "The mapping
> functions for converting a pointer to an integer or an integer to a
> pointer are intended to
> be consistent with the addressing structure of the execution environment."
>  
> 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 integer constant expression or an
> arithmetic expression with an integer value of zero. If the former,
> then the pointer is compared against the null pointer constant per
> §6.3.2.3 ¶4. If the latter, the pointer is converted to integer per
> implementation-defined behavior and the comparison is performed, which
> might itself result in undefined behavior per §6.5 ¶5 since the
> conversion is not guaranteed to produce a value within range of any
> integer type.
>  
> In practice, it's a moot point since on all architectures that Apple's
> Objective-C runtime runs on use identical bit patterns for null
> pointers as they do for integer zero.
>  
> But absent any information I'm unaware of, the explicit comparison is
> "more correct" in the sense that it doesn't leave any room for
> implementation-defined behavior.
>  
> --Kyle Sluder  

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

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 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 variant, but I'm wondering if the
> second one is more correct?
>
> The "nil" is defined as follows (jumped to definition)
>
> #define nil NULL
> #define NULL ((void*)0)
>
> 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" statement, it's
> implicitly cast to the type "boolean".
>
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
>
> Thoughts?
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[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 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 variant, but I'm wondering if the
> second one is more correct?
>
> The "nil" is defined as follows (jumped to definition)
>
> #define nil NULL
> #define NULL ((void*)0)
>
> 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" statement, it's
> implicitly cast to the type "boolean".
>
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.

§6.3.2.3 ¶3 defines the null pointer constant as "an integer constant
expression with the value 0, or such an expression cast to type void
*". A null pointer is one that has been assigned the value of the null
pointer constant, or has been assigned the value of another null
pointer.

But you are correct that conversion of a null pointer to integer is
NOT defined to compare equal to an integer expression with a value of
zero. §6.3.2.3 ¶6 makes that clear: "Any pointer type may be converted
to an integer type. Except as previously specified, the result is
implementation-defined." However, footnote 56 states that "The mapping
functions for converting a pointer to an integer or an integer to a
pointer are intended to
be consistent with the addressing structure of the execution environment."

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 integer constant expression or an
arithmetic expression with an integer value of zero. If the former,
then the pointer is compared against the null pointer constant per
§6.3.2.3 ¶4. If the latter, the pointer is converted to integer per
implementation-defined behavior and the comparison is performed, which
might itself result in undefined behavior per §6.5 ¶5 since the
conversion is not guaranteed to produce a value within range of any
integer type.

In practice, it's a moot point since on all architectures that Apple's
Objective-C runtime runs on use identical bit patterns for null
pointers as they do for integer zero.

But absent any information I'm unaware of, the explicit comparison is
"more correct" in the sense that it doesn't leave any room for
implementation-defined behavior.

--Kyle Sluder

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[David Rowland]

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 form you will see,

if (self = [super init])  .

It compacts the assignment into the boolean. It works, but putting an 
assignment into a boolean is treading close to the edge of being misleading. 
Too clever by half, as the British say.

David







On 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];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
> 
> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)
> 
> 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" statement, it's
> implicitly cast to the type "boolean".
> 
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?
> ___
> 
> 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-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/rowlandd%40sbcglobal.net
> 
> This email sent to rowla...@sbcglobal.net


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Wade Tregaskis]

> 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 
values, though an explicit test against nil is fine if that's your preference.

> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)

I'd hazard to say that's an implementation detail.  While you can compare 
object pointers against NULL, it's strongly against convention - you use nil 
for pointers to ObjC objects, NULL for other types of pointers.  Hypothetically 
this protects you from any future changes in how objects are distinguished from 
"regular" pointers.

> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.


That definition is quite archaic.  Though technically speaking it's true, and 
is thus an argument for actually using NULL rather than 0, it's not the only 
such argument by far*, and in any case there's enough momentum behind NULL == 0 
that this will almost certainly never change.

* = For example, more important arguments are for readability in code, and 
because 0 is an integer whereas pointers are not.  And that a test against zero 
is faster than a test against any other specific integer on all modern hardware.
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

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 dawn of time, not that it's 
quirky. The if(self != nil) is perfectly correct as well, but adds nothing 
except satisfying some people's personal preference--the only people I've ever 
seen argue strongly in favor of it are ones who learned Pascal before C...

Yes, the underlying value of the NULL pointer may not be 0 on some 
architectures, but the language guarantees that if(self) will evaluate as you 
expect if self is the null pointer (and that assigning constant 0 to a pointer 
will set it to the null pointer). The few people who argue that if(self) is not 
portable are simply wrong.

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 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 you're going to 
insist on the verbose version, you might as well use if(nil == self).

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Thomas Davie]

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 you.

If you on the other hand like to hold a stronger type system than C's in your 
head, and like to think of if statements as things that accept boolean 
arguments, and execute the first branch if the boolean is true, then clearly if 
(self) is an "in head" type error - you need to compare against nil to get a 
boolean out.

Hope that clarifies things.

Bob
if (*ra4 != 0xffc78948) { return false; }

On 24 Feb 2012, at 14:50, 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 != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
> 
> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)
> 
> 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" statement, it's
> implicitly cast to the type "boolean".
> 
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?
> ___
> 
> 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-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/tom.davie%40gmail.com
> 
> This email sent to tom.da...@gmail.com

___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Keary Suska]

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 != nil)
> {
> }
> return self;

It may really boil down to a stylistic issue, but I believe that the "self != 
nil" syntax is the most canonical.

> 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.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Fritz Anderson]

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 != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?

It's a matter of style; neither is "more correct." C has always guaranteed that 
in source (if not necessarily in the target architecture), NULL pointers can be 
treated as 0.

if (self)
and
if (self != nil)

should produce identical code. Some people find the second easier to read. I 
find the first to be so fundamental an idiom that anyone who can't understand 
it has no business working with C.

> 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" statement, it's
> implicitly cast to the type "boolean".

C, earlier than C99, has no concept of a Boolean. Conditionals are not false or 
true, but zero (or NULL) or non-zero. C99 has a bool (_Bool) type, but has to 
conform to the 0/non-0 rule. Boolean operators reduce true expressions to 1, 
but code that relies on 1 (or true, or YES) being the only non-false value is 
incorrect.

— F


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[David Duncan]

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" statement, it's
> implicitly cast to the type "boolean".

In C any non-zero value is 'true', as such if (self) vs if (self != nil) is a 
pure stylistic choice, neither is more correct than the other in terms of the 
language itself.
--
David Duncan


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Obj-C] if (self) vs. if (self != nil)

[Howard Moon]

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 multiple 
conditions or simply trying to read my code later. I'm a big believer in using 
parentheses around sub-conditions as well, and never simply relying on order of 
evaluation.

I know there are many (esp. C programmers) who prefer the most abbreviated 
format possible, but I go the opposite way, always wanting to be able to easily 
read what I've written. After all, the symbols themselves will go away once 
compiled, and the extra time and space for the characters is inconsequential 
(these days) when compared to the need to easily identify what the heck you've 
written! :-)

-Howard


On 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];
> if (self != nil)
> {
> }
> return self;
> 
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
> 
> The "nil" is defined as follows (jumped to definition)
> 
> #define nil NULL
> #define NULL ((void*)0)
> 
> 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" statement, it's
> implicitly cast to the type "boolean".
> 
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
> 
> Thoughts?
> ___


___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[Obj-C] if (self) vs. if (self != nil)

[Oleg Krupnov]

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 variant, but I'm wondering if the
second one is more correct?

The "nil" is defined as follows (jumped to definition)

#define nil NULL
#define NULL ((void*)0)

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" statement, it's
implicitly cast to the type "boolean".

I also heard that generally speaking NULL is not necessarily always
equal to 0 on all architectures.

Thoughts?
___

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-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com