Re: !foo vs foo == nil
Am Do,21.08.2008 um 19:54 schrieb Michael Ash: On Thu, Aug 21, 2008 at 10:40 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,21.08.2008 um 16:15 schrieb Michael Ash: On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier: Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin: Sometimes you see in source code something like this: if( booleanVarOrExpression == YES ) (I think, Rentzsch does it that way, IIRC) and Ithink, that this is simply correct. Oh, that is another discussion. Yeah, but connected It is antoher discussion in that way, that we have other types. (BOOL vs. type of logical expression in C) It is the same discussion in that way, that most programmers make some assumptions about the value (and the casting). (I bet, that 10 % believe, that the expression inside the if is typed BOOL) I'd be very surprised at this, given that BOOL is found only in Objective-C, and if statements are found in C. IIRC this depends on the concrete standard? No, it does not. Objective-C does not have a standard, and no C standard includes BOOL. Objective-C has a reference. The reference includes BOOL. BOOL A Boolean value, either YES or NO. Doing this is absolutly correct. BOOL var = …; // Something evaluating to YES or NO if( var == YES ) It's correct in that it is a legal language construct and it has well-defined results. But it is incorrect as far as doing what most people would want it to do. Consider this: BOOL var = 2; If somebody wants to do this, he does something wrong. 2 is no valid assignment for a BOOL. Of course it's valid: typedef signed char BOOL; This is an implementation detil. You should see the difference between reference and implementation. This is basical. Beside this, you misunderstood the meaning of types. If somebody defines a type, he gives the new type a semantical meaning. Otherwise there is no need to define a new type. When $somebody started to define BOOL, bool, Boolean, boolean … he wanted to say, that this a boolean value. Valid boolean values are YES ans NO. (or TRUE and FALSE or True and False or true and false - but boolean values). The C standard guarantees that a signed char can hold at least values in the range of -127 to 127. Depending on the implementation, it may be abel to hold more. Thus any number in that range is a valid value for a variable of type BOOL. There is a conception about types. It is not rolling the dices. if(var == YES) That if statement will evaluate to false, even though the value of var is conceptually true. There is no conpetionally true. BOOL has the valid values YES and NO, not 2, not CONCEPTIONALLYYES. No, BOOL has the valid values -127 through 127, and possibly more. In the C language, all non-zero values are true. No, it has the valid vlues YES and NO. This is defined by the language reference. (True in C meaning anything that is not zero.) This is not a BOOL. *You* said, that there is no bool in C. No, I said that there is no BOOL in C. Of course, when discussion about different languages, it is strange to refer to a series of lettrs. Shall I start to write BOOL, Bool bool, Boolean, boolean? There is an idea of booleans. This idea is not related to programming languages or a specific programming language. And it is not the idea of boolean numbers, that there is a pari 0, !0. It is the idea, that there is a pair YES and NO (or TRUE and FALSE or true and false … The idea does not depend on a specific language) Thinking about the concept type you sould realize, that types are not made for a special series of characters to name it, but a semantical conception, meaning. Of course it is also true that there is no bool in C. And it's true. But C does have the concept of logical truth and falsehood, it's just not expressed by means of a boolean type, or boolean values. Exactly. But in Objective-C it is expressed by a boolean type. The logical truth in an if-statement bases on the difference betwenn == 0 and != 0, The logical truth of a boolean type in Objective-C is based on YES and NO. BOOL A Boolean value, either YES or NO. This is, what I said. so if( boolean ) changes the type. It only works, because NO is defined as 0 and YES is defined to something else then 0. As I said hours ago, this is disclused by the reference, so in Objective-C you can use this assumption without danger. But you *need* that, because logical expressions and BOOLs are not the same. An if takes no BOOL, but the type of an logical expression. There is no such thing in the C language as type of an logical expression. Typically logical expression is the term for the superset of relational expressions and expressions with logical operators. They have in common, that they only accepts the values related to truth and falseness. This term isn't inveted by me. I. e.:
Re: !foo vs foo == nil
On 22/08/2008, at 00.38, Andy Lee wrote: On Aug 21, 2008, at 3:42 PM, Jim Correia wrote: On Aug 21, 2008, at 3:54 AM, Jules Colding wrote: For that simple reason, I'd go for nil == foo every time. Yes, and in general you should always do if (CONSTANT == foo) to catch the potential if (CONSTANT = foo) error. If your name is Yoda, then perhaps if (3 != x) reads naturally to you. :-) Actually it does even though my name isn't Yoda ;-) Anyway, it is a matter of personal taste what style you choose. I just happen to prefer to put the constant first. An old habit I guess... Best regards, jules As in most things, I think it is critical to strike a balance between code readability/skim-ability and other considerations. I keep changing my mind about this, so my code is inconsistent about it, but I've basically come to the same conclusion. One thing I've noticed is that I rarely get a bug due to misreading a boolean expression. More often I'm looking right at it (even if it's as unmistakeable as nil == obj) and I do the wrong thing anyway. Like I'll get the if-block and the else-block mixed up. It's like some kind of boolean-dyslexia in my brain. I find it helps to comment my logic. --Andy ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Wow, I'm simply blown away at the level of confusion. I've been doing C for a long long time. Prior to C99 there was no boolean type in C. I have never missed it. I have never ever seen a bug introduced by doing code like if(foo) or if(!foo) I have seen a large number of bugs introduced by programmers trying to make a boolean type for C and a lot of bugs introduced by trying to test for explicit trueness or nullness with code like if(foo == true) or if(foo = NULL) and so forth. I have also spent a lot of time devising clever macros to work around conflicting boolean types in other people's libraries. All of the right things happen if you simply accept that zero in all of its forms is false and not zero is true. All of the trouble comes when trying to define what is true or trying to write a comparison expression when simply testing the value of the variable would do. Put me firmly in the if(foo) camp. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 21/08/2008, at 01.56, John C. Randolph wrote: On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. Which is why you should always write if (nil == foo). -- jules ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 21 Aug 2008, at 09:06, Jules Colding wrote: On 21/08/2008, at 01.56, John C. Randolph wrote: On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. Which is why you should always write if (nil == foo). Just to add my 2 cents to this discussion, I think there's something which hasn't been brought up (and I guess isn't often brought up by C programmers). One of the two options doesn't make sense here. Because of C's weak type system ! works on almost anything you throw at it. However, it is a *boolean* operator. Boolean negating a pointer is a hack that by happy coincidence works. On the other hand, nil == foo is type safe, and makes semantic sense. For that simple reason, I'd go for nil == foo every time. Bob ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
haha gros malin why free (func) does this test? arf sorry your trusting scale is going to zero Not sure what you're trying to say. According to the C standard, given a variable (foo) the following are identical: if(foo == 0) if(foo == nil) if(foo == NULL) if(!foo) if(foo == '0') and any other way you can compare to a literal zero. I hope this is a typo but '0' != 0, so the last line is not a valid way to test for nullity (but foo == '\0' is). ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 21/08/2008, at 09.21, Thomas Davie wrote: On 21 Aug 2008, at 09:06, Jules Colding wrote: On 21/08/2008, at 01.56, John C. Randolph wrote: On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. Which is why you should always write if (nil == foo). Just to add my 2 cents to this discussion, I think there's something which hasn't been brought up (and I guess isn't often brought up by C programmers). One of the two options doesn't make sense here. Because of C's weak type system ! works on almost anything you throw at it. However, it is a *boolean* operator. Boolean negating a pointer is a hack that by happy coincidence works. On the other hand, nil == foo is type safe, and makes semantic sense. For that simple reason, I'd go for nil == foo every time. Yes, and in general you should always do if (CONSTANT == foo) to catch the potential if (CONSTANT = foo) error. Best regards, jules ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Cheap quality improvements (was Re: !foo vs foo == nil)
On 21 Aug 2008, at 04:03, Michael Ash wrote: This hazard goes away if you turn on the appropriate warnings. I compile all of my code with -W -Wall -Wno-unused-parameter, and it has caught much more than just this error over the years. [getting slightly off topic] Speaking as a battle-hardened QA manager, the one simple step of turning on all warnings and removing them is one of the cheapest ways possible to improve the quality of the output of a dev team[1]. I'm astounded that pretty much every commercial dev team I've worked with have been content to check in code with warnings until I harangue them about it. Also amazing is that they all KNEW what -Wall and -Werror do but were content not to bother with them. Neil. [1] Of course firing the chaff is cheaper in the short term, but is not always seen as a pragmatic option when projects are underway. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 12:21 AM, Thomas Davie [EMAIL PROTECTED] wrote: On 21 Aug 2008, at 09:06, Jules Colding wrote: On 21/08/2008, at 01.56, John C. Randolph wrote: On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. Which is why you should always write if (nil == foo). Just to add my 2 cents to this discussion, I think there's something which hasn't been brought up (and I guess isn't often brought up by C programmers). One of the two options doesn't make sense here. It may not make sense to those who aren't used to C (or, more accurately, are *more* used to another language), but it makes perfect sense to C programmers (just as [foo method: bar] doesn't make sense to C programmers, but makes perfect sense to Obj-C programmers). Different languages have different idioms. C programmers likely tend not to bring it up, because it is second nature to them. Because of C's weak type system ! works on almost anything you throw at it. However, it is a *boolean* operator. Boolean negating a pointer is a hack that by happy coincidence works. This is not a hack or a coincidence, this is by design. A non-NULL pointer *is* a boolean expression that evaluates to true, just as a non-zero integer is. Again, it doesn't work by coincidence, it is a guarantee of the language standard. Note, that the same is true in C++, which has a much stronger type system than C. On the other hand, nil == foo is type safe, and makes semantic sense. For that simple reason, I'd go for nil == foo every time. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 12:39 AM, Jean-Daniel Dupas [EMAIL PROTECTED] wrote: haha gros malin why free (func) does this test? arf sorry your trusting scale is going to zero Not sure what you're trying to say. According to the C standard, given a variable (foo) the following are identical: if(foo == 0) if(foo == nil) if(foo == NULL) if(!foo) if(foo == '0') and any other way you can compare to a literal zero. I hope this is a typo but '0' != 0, so the last line is not a valid way to test for nullity (but foo == '\0' is). Indeed, I lost a backslash there :) -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Le 21 août 08 à 10:06, Clark Cox a écrit : On Thu, Aug 21, 2008 at 12:21 AM, Thomas Davie [EMAIL PROTECTED] wrote: On 21 Aug 2008, at 09:06, Jules Colding wrote: On 21/08/2008, at 01.56, John C. Randolph wrote: On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. Which is why you should always write if (nil == foo). Just to add my 2 cents to this discussion, I think there's something which hasn't been brought up (and I guess isn't often brought up by C programmers). One of the two options doesn't make sense here. It may not make sense to those who aren't used to C (or, more accurately, are *more* used to another language), but it makes perfect sense to C programmers (just as [foo method: bar] doesn't make sense to C programmers, but makes perfect sense to Obj-C programmers). Different languages have different idioms. C programmers likely tend not to bring it up, because it is second nature to them. Because of C's weak type system ! works on almost anything you throw at it. However, it is a *boolean* operator. Boolean negating a pointer is a hack that by happy coincidence works. This is not a hack or a coincidence, this is by design. A non-NULL pointer *is* a boolean expression that evaluates to true, just as a non-zero integer is. Again, it doesn't work by coincidence, it is a guarantee of the language standard. Note, that the same is true in C++, which has a much stronger type system than C. Agree with that. And remember that the bool type is a recent addition and was not defined in the first C language version. So it's perfectly valid to use the '!' operator on something that is not a boolean. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Am Do,21.08.2008 um 09:54 schrieb Jules Colding: On 21/08/2008, at 09.21, Thomas Davie wrote: On 21 Aug 2008, at 09:06, Jules Colding wrote: On 21/08/2008, at 01.56, John C. Randolph wrote: On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. Which is why you should always write if (nil == foo). Just to add my 2 cents to this discussion, I think there's something which hasn't been brought up (and I guess isn't often brought up by C programmers). One of the two options doesn't make sense here. Because of C's weak type system ! works on almost anything you throw at it. However, it is a *boolean* operator. Boolean negating a pointer is a hack that by happy coincidence works. On the other hand, nil == foo is type safe, and makes semantic sense. For that simple reason, I'd go for nil == foo every time. Yes, and in general you should always do if (CONSTANT == foo) to catch the potential if (CONSTANT = foo) error. You should always compile with -Wall to catch potential if( value1 = value2 ) even if value1 is no constant. Cheers, Amin Best regards, jules ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de This email sent to [EMAIL PROTECTED] Amin Negm-Awad [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Am 21.08.2008 um 05:03 schrieb Michael Ash: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. This is true conceptually but not as far as their actual definition. NULL can be either 0 or (void *)0. Let's be a little bit more precise, I'll try to paraphrase correctly from my memory: a.) (int) NULL is NOT required or guaranteed 0x0 by the standard. This is why one should never use if( anPtr == (void *) 0 ); instead of if( anPtr == NULL ); On modern machines, it usually is. b.) At least the C++ standard mandates for type conversion of an pointer to an boolean, that e.g. ( !anPtr ) is equivalent to ( ! (anPtr == NULL )). I didn't read the C99 spec but I'm sure there is something similar specified. This implementation detail does probably not matter on most platforms today as even microcontrollers have AFAIK linear address spaces. When I was writing my first C app on a DOS machine, there were segmented addresses. That meant it could happen that ((somePtr + offset) - offset) == somePtr evaluated to false - (somePtr + offset) changed the segment, anotherPtr - offset did not. Big debug surprise for poor little 68020 fanboy ;-) Regards, Tom_E ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Am 21.08.2008 um 05:25 schrieb Clark Cox: Not sure what you're trying to say. According to the C standard, given a variable (foo) the following are identical: if(!foo) if(foo == '0') YIKES! (NULL == (char_type_t) 0x30 ) != ( NULL == '0' ) ? C99 or C99 + C++98? Regards, Tom_E ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Am Do,21.08.2008 um 10:47 schrieb Thomas Engelmeier: Am 21.08.2008 um 05:03 schrieb Michael Ash: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. This is true conceptually but not as far as their actual definition. NULL can be either 0 or (void *)0. Let's be a little bit more precise, I'll try to paraphrase correctly from my memory: a.) (int) NULL is NOT required or guaranteed 0x0 by the standard. This is why one should never use if( anPtr == (void *) 0 ); instead of if( anPtr == NULL ); On modern machines, it usually is. b.) At least the C++ standard mandates for type conversion of an pointer to an boolean, that e.g. ( !anPtr ) is equivalent to ( ! (anPtr == NULL )). I didn't read the C99 spec but I'm sure there is something similar specified. This implementation detail does probably not matter on most platforms today as even microcontrollers have AFAIK linear address spaces. When I was writing my first C app on a DOS machine, there were segmented addresses. That meant it could happen that ((somePtr + offset) - offset) == somePtr evaluated to false - (somePtr + offset) changed the segment, anotherPtr - offset did not. Big debug surprise for poor little 68020 fanboy ;-) First: Thanks a lot! I wanted to write somthing like this, but … I always say, that theoretically it is dangerous to relay on NO = 0 and nil = 0 (The assumption YES = 1 is simply wrong on some machines). In practice of course this always works. But in the documentation of Objective-C 2 from Apple, the definitions of NO and nil are diclosed. So I think, now it is for (and only for) Objective-C 2 official that NO and nil equals to 0. Sometimes you see in source code something like this: if( booleanVarOrExpression == YES ) (I think, Rentzsch does it that way, IIRC) and Ithink, that this is simply correct. Cheers, Amin Regards, Tom_E ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de This email sent to [EMAIL PROTECTED] Amin Negm-Awad [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin: Sometimes you see in source code something like this: if( booleanVarOrExpression == YES ) (I think, Rentzsch does it that way, IIRC) and Ithink, that this is simply correct. Oh, that is another discussion. Bool != Boolean != bool, and sometimes that can introduce subtle errors if it's not only used to evaluate logical statements but by comparing values, especially to YES, true and TRUE. In an large C++ Cross-Platform project I spotted some subtle problems, IIRC from assignment of an bool to an Boolean for an API that evaluated the values by comparison to TRUE or some code assigned it to ints, giving different values for true (1 vs. 0xFF vs. 0x). I don't know any more, fixed it, was glad my own coding practices don't leave room for that problems, moved on ;-)... Regards, Tom_E ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 21 Aug 2008, at 09:06, Clark Cox wrote:
This is not a hack or a coincidence, this is by design. A non-NULL
pointer *is* a boolean expression that evaluates to true, just as a
non-zero integer is. Again, it doesn't work by coincidence, it is a
guarantee of the language standard.
To go off on a bit of a tangent, if you read this without thinking of
all the implications of other parts of the language you /can/ still
run into problems. For example:
BOOL b = (BOOL)v;
could leave you with b == NO even if v != 0.
If BOOL is a shorter type than value's type (e.g. if BOOL is char and
v is long), and if the lower bits of v are all 0 but the higher bits
are not, the higher bits will just get truncated off in the conversion.
i.e. this:
---
#include Foundation/Foundation.h
int main() {
int myFlags = 0x01000200;
int myBitMask = 0x0100;
BOOL isFlagSet = (BOOL)(myFlags myBitMask);
if(isFlagSet == NO) { // Could (of course) use if(!isMasked)
here, I just used this for clarity
printf(Oh No!\n);
}
return 1;
}
---
gives:
---
Thing:tmp jamie$ gcc test.m -framework Foundation
Thing:tmp jamie$ ./a.out
Oh No!
---
This has puzzled me for a while in the past when I was wondering why
my bit masks were not evaluating correctly.
Jamie.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier: Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin: Sometimes you see in source code something like this: if( booleanVarOrExpression == YES ) (I think, Rentzsch does it that way, IIRC) and Ithink, that this is simply correct. Oh, that is another discussion. Yeah, but connected It is antoher discussion in that way, that we have other types. (BOOL vs. type of logical expression in C) It is the same discussion in that way, that most programmers make some assumptions about the value (and the casting). (I bet, that 10 % believe, that the expression inside the if is typed BOOL) Doing this is absolutly correct. BOOL var = …; // Something evaluating to YES or NO if( var == YES ) a simple BOOL var = …; // Something evaluating to YES or NO if( var ) is a very good hidden implicit cast from BOOL to logical expression. However I use the simple condition (without == YES), too – for convenience. BTW: This is an implicit cast, too: BOOL var = a b; because the result of the right expression types to logical expression, not to BOOL. Bool != Boolean != bool, and sometimes that can introduce subtle errors if it's not only used to evaluate logical statements but by comparing values, especially to YES, true and TRUE. Yes, and some people do calculations with it andExpression = a * b, // of course in a more subtle context orExpression = a + b; // argh … In an large C++ Cross-Platform project I spotted some subtle problems, IIRC from assignment of an bool to an Boolean for an API that evaluated the values by comparison to TRUE or some code assigned it to ints, giving different values for true (1 vs. 0xFF vs. 0x). I don't know any more, fixed it, was glad my own coding practices don't leave room for that problems, moved on ;-)... :-) Regards, Tom_E LG Amin Negm-Awad [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 21, 2008, at 4:47 AM, Thomas Engelmeier wrote:
Am 21.08.2008 um 05:03 schrieb Michael Ash:
There was a common perception that NULL is not really the same
as nil. But
seems like in the end it really is (void*)0.
They differ in type, not in value.
NULL is (void *) 0.
nil is (id) 0.
Nil is (Class) 0.
This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.
Let's be a little bit more precise, I'll try to paraphrase
correctly from my memory:
a.)
(int) NULL is NOT required or guaranteed 0x0 by the standard.
This is why one should never use
if( anPtr == (void *) 0 );
instead of
if( anPtr == NULL );
On modern machines, it usually is.
But Stroustrup says NULL is defined as 0 (zero) in C++.
http://www.research.att.com/~bs/bs_faq2.html#null
With my C++ background, I normally write:
if (thePtr) {
// do things
}
else {
// error handling
}
Btw, I recall reading something in the PPC days that the expected
case should put first so the compiler can optimize better (branch
prediction?).
b.) At least the C++ standard mandates for type conversion of an
pointer to an boolean, that e.g. ( !anPtr ) is equivalent to ( !
(anPtr == NULL )). I didn't read the C99 spec but I'm sure there is
something similar specified.
This implementation detail does probably not matter on most
platforms today as even microcontrollers have AFAIK linear address
spaces.
When I was writing my first C app on a DOS machine, there were
segmented addresses. That meant it could happen that
((somePtr + offset) - offset) == somePtr
evaluated to false - (somePtr + offset) changed the segment,
anotherPtr - offset did not. Big debug surprise for poor little
68020 fanboy ;-)
Regards,
Tom_E
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 21.08.2008, at 02:43, Torsten Curdt wrote: On Aug 21, 2008, at 01:50, Ken Thomases wrote: On Aug 20, 2008, at 6:15 PM, Torsten Curdt wrote: I guess my questions wasn't phrased correctly. The point was more: is 'nil' really the equivalent of 0 or NULL. Let's put it this way: freshly allocated objects have their memory zeroed out, Why should that affect the pointer to an object? I think what he meant to say is that, since Apple guarantees stuff will be zeroed out, and much code already relies on ivars that have pointer types being nil, it's unlikely that NULL will not be binary- equivalent to one or more zeroes, because that would break pretty much all code. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 21, 2008, at 7:57 AM, Sam Mo wrote:
On Aug 21, 2008, at 4:47 AM, Thomas Engelmeier wrote:
Am 21.08.2008 um 05:03 schrieb Michael Ash:
There was a common perception that NULL is not really the same
as nil. But
seems like in the end it really is (void*)0.
They differ in type, not in value.
NULL is (void *) 0.
nil is (id) 0.
Nil is (Class) 0.
This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.
Let's be a little bit more precise, I'll try to paraphrase
correctly from my memory:
a.)
(int) NULL is NOT required or guaranteed 0x0 by the standard.
This is why one should never use
if( anPtr == (void *) 0 );
instead of
if( anPtr == NULL );
On modern machines, it usually is.
But Stroustrup says NULL is defined as 0 (zero) in C++.
http://www.research.att.com/~bs/bs_faq2.html#null
With my C++ background, I normally write:
if (thePtr) {
// do things
}
else {
// error handling
}
Btw, I recall reading something in the PPC days that the expected
case should put first so the compiler can optimize better (branch
prediction?).
apparently this is also discussed in C-FAQ:
http://c-faq.com/null/ptrtest.html
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier: Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin: Sometimes you see in source code something like this: if( booleanVarOrExpression == YES ) (I think, Rentzsch does it that way, IIRC) and Ithink, that this is simply correct. Oh, that is another discussion. Yeah, but connected It is antoher discussion in that way, that we have other types. (BOOL vs. type of logical expression in C) It is the same discussion in that way, that most programmers make some assumptions about the value (and the casting). (I bet, that 10 % believe, that the expression inside the if is typed BOOL) I'd be very surprised at this, given that BOOL is found only in Objective-C, and if statements are found in C. Doing this is absolutly correct. BOOL var = …; // Something evaluating to YES or NO if( var == YES ) It's correct in that it is a legal language construct and it has well-defined results. But it is incorrect as far as doing what most people would want it to do. Consider this: BOOL var = 2; if(var == YES) That if statement will evaluate to false, even though the value of var is conceptually true. (True in C meaning anything that is not zero.) For this reason, I recommend never comparing with YES. If you are mentally unable to simply write if(var), then I recommend using if(var != NO). I consider any code that compares against YES as you wrote to have a bug. a simple BOOL var = …; // Something evaluating to YES or NO if( var ) is a very good hidden implicit cast from BOOL to logical expression. There is no hidden implicit cast. The if statement simply checks its contents for truth or falseness, which is to say that it checks it for zero or non-zero. However I use the simple condition (without == YES), too – for convenience. Your code then has a bug, in my opinion, and this is likely to manifest in ways extremely annoying and difficult to diagnose. BTW: This is an implicit cast, too: BOOL var = a b; because the result of the right expression types to logical expression, not to BOOL. No, the right side of the expression is typed *int*. There is no such C type as logical expression. I recommend you learn more about the C language before you continue any further, because you have a lot of misconceptions and many of them are going to cause you to write bad code. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Am Do,21.08.2008 um 16:15 schrieb Michael Ash: On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier: Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin: Sometimes you see in source code something like this: if( booleanVarOrExpression == YES ) (I think, Rentzsch does it that way, IIRC) and Ithink, that this is simply correct. Oh, that is another discussion. Yeah, but connected It is antoher discussion in that way, that we have other types. (BOOL vs. type of logical expression in C) It is the same discussion in that way, that most programmers make some assumptions about the value (and the casting). (I bet, that 10 % believe, that the expression inside the if is typed BOOL) I'd be very surprised at this, given that BOOL is found only in Objective-C, and if statements are found in C. IIRC this depends on the concrete standard? Doing this is absolutly correct. BOOL var = …; // Something evaluating to YES or NO if( var == YES ) It's correct in that it is a legal language construct and it has well-defined results. But it is incorrect as far as doing what most people would want it to do. Consider this: BOOL var = 2; If somebody wants to do this, he does something wrong. 2 is no valid assignment for a BOOL. if(var == YES) That if statement will evaluate to false, even though the value of var is conceptually true. There is no conpetionally true. BOOL has the valid values YES and NO, not 2, not CONCEPTIONALLYYES. (True in C meaning anything that is not zero.) This is not a BOOL. *You* said, that there is no bool in C. An if takes no BOOL, but the type of an logical expression. For this reason, I recommend never comparing with YES. You should recommend, to assign never something else then YES or NO to a BOOL. *This* is wrong. If you are mentally unable to simply write if(var), I'm not mentally unable to write that and I said, that I do that. However I use the simple condition (without == YES), too – for convenience. then I recommend using if(var != NO). I consider any code that compares against YES as you wrote to have a bug. No, BOOL var = 2; has a bug. a simple BOOL var = …; // Something evaluating to YES or NO if( var ) is a very good hidden implicit cast from BOOL to logical expression. There is no hidden implicit cast. The if statement simply checks its contents for truth or falseness, No, it checks for == 0 or != 0. BOOLs contain YES and NO. which is to say that it checks it for zero or non-zero. Yup, and *not* for YES or NO However I use the simple condition (without == YES), too – for convenience. Your code then has a bug, in my opinion, and this is likely to manifest in ways extremely annoying and difficult to diagnose. No, your code has a bug: BOOL var = 2; BTW: This is an implicit cast, too: BOOL var = a b; because the result of the right expression types to logical expression, not to BOOL. No, the right side of the expression is typed *int*. There is no such C type as logical expression. You cannot use it explicitly, but it is a construction of the language. The check of if is on == 0 or != 0. This is less then an int (or whatever you use) and something else than a BOOL. I recommend you learn more about the C language before you continue any further, because you have a lot of misconceptions and many of them are going to cause you to write bad code. I do not think so. But *I* would never assing 2 to a BOOL. And I'm sure doing so is a misconception. Cheers, Amin Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de This email sent to [EMAIL PROTECTED] Amin Negm-Awad [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 1:47 AM, Thomas Engelmeier [EMAIL PROTECTED] wrote: Am 21.08.2008 um 05:03 schrieb Michael Ash: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. This is true conceptually but not as far as their actual definition. NULL can be either 0 or (void *)0. Let's be a little bit more precise, I'll try to paraphrase correctly from my memory: a.) (int) NULL is NOT required or guaranteed 0x0 by the standard. This is why one should never use if( anPtr == (void *) 0 ); instead of if( anPtr == NULL ); On modern machines, it usually is. This is not true. Those two expressions are identical as far as C is concerned, on any machine with a conforming C implementation (i.e. (void*)0 and NULL are both valid null pointer constants.) I think you are trying to say that the *representation* of a null pointer needn't necessarily be all-bits-zero (i.e. you won't always get a null pointer if you bzero/or memset it to zero). In that, you are correct, but that is orthogonal to the discussion here (and there is currently no C implementation with such null pointers that I know of). b.) At least the C++ standard mandates for type conversion of an pointer to an boolean, that e.g. ( !anPtr ) is equivalent to ( !(anPtr == NULL )). I believe you mean that (!anPtr) is equivalent to (anPtr == NULL), in which case, you are correct for C and C++. I didn't read the C99 spec but I'm sure there is something similar specified. This implementation detail This is not an implementation detail, it is a guarantee of the standards, and is essential to the C and C++ languages. does probably not matter on most platforms today as even microcontrollers have AFAIK linear address spaces. The above is true on *any* C implementation, even those without a linear address space. When I was writing my first C app on a DOS machine, there were segmented addresses. That meant it could happen that ((somePtr + offset) - offset) == somePtr evaluated to false - (somePtr + offset) changed the segment, anotherPtr - offset did not. Big debug surprise for poor little 68020 fanboy ;-) Indeed, but this is also a separate issue, even on DOS, (!anPtr) is equivalent to (anPtr == NULL). Unless somePtr is a pointer to an array or object that is at least (offset - 1) bytes in size, then ((somePtr + offset) - offset) causes undefined behavior on any platform (it just dosen't usually manifest on platforms with a linear address space) -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
[moderator] Re: !foo vs foo == nil
mm w
The list isn't a quiz show. If you have an answer, please provide it
in full, perhaps with a bit of an explanation.
Otherwise you're risking moderation for offering little support (and
lots of confusion)
scott
[moderator]
On 20-Aug-08, at 9:15 PM, mm w wrote:
anyway I m going to add a hint
as a previous oppenant said yeh dude it's normal it's undefined/
nothin nada :)
int main(void) {g
char *p1;
char *p2 = NULL;
if(!p1)
puts(hello p1);
if(!p2)
puts(hello p2);
return 0;
}
output hello p2
On Wed, Aug 20, 2008 at 6:00 PM, mm w [EMAIL PROTECTED] wrote:
ok Im like a puppy I like to play, I will stop to play the evil
advogate for 98% of cases
here my late Initialization:
we can say (!toto) is the same of toto == NULL
but the Douglas pointed something really interesting... let see ahead
On Wed, Aug 20, 2008 at 5:39 PM, Andrew Merenbach
[EMAIL PROTECTED] wrote:
With all due respect, this seems a little more confusing than
enlightening.
Alignment has little to do with the question, as far as I can
see. Would
you be so kind as to explain what bearing your answer has on the
original
poster's question?
-- Andrew
On Aug 20, 2008, at 3:29 PM, mm w wrote:
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
char *p2 = NULL;
free(p1);
free(p2);
return 0;
}
if (toto)... just align your answer
On Wed, Aug 20, 2008 at 3:23 PM, Torsten Curdt [EMAIL PROTECTED]
wrote:
This question has come up during the last CocoaHeads and no one
was
really
able to give a definite answer.
Do both expressions really mean the same thing (as nil is not
null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/andrew.merenbach%40ucla.edu
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
[moderator] Re: !foo vs foo == nil
it appears that mm w has left the list in the middle of this thread. I think it's quite safe to assume there was more than a little trolling on his part. scott [moderator] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 8/21/08 10:15 AM, Michael Ash said: BOOL var = 2; if(var == YES) That if statement will evaluate to false, even though the value of var is conceptually true. If only BOOL was bool we would not have this problem. :) To the best of my knowledge, there is no compiler flag to catch comparing a BOOL to YES. Anyone know of a way? -- Sean McBride, B. Eng [EMAIL PROTECTED] 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Wow, don't check the list for a few days and look what happens! After all, that's why nil (and Nil) exist at all, rather than just reusing NULL. Actually nil exists at all because Objective-C was created *before* NULL was in such standard use! (It may have always been part of stdio.h, don't recall for sure, but there definitely was no stddef.h.) Way back when, everybody defined their own macro, and some libraries even called it NIL or nil or null instead of NULL. (Others simply used 0.) I finally discovered that one of the headers in this old cross-platform code had defined NULL to be 0, just a plain integer 0, rather than (void *)0. Yes, that is allowed. In fact, Stroustrup suggests that it is preferred for C++, because stricter type checking makes ((void*)0) much less useful... GCC (actually g++) gets around this by providing __null, which is a magic token that gets special treatment from the compiler. If you look at stddef.h and/or _types.h, you'll see a special case for __GNUG__ (GNU C++) that defines NULL to be __null. It is a little known fact that when passing NULL (and by extension nil or Nil) as a parameter to a vararg function, you *must* cast it to the appropriate pointer type to guarantee correct behavior. 2 reasons: 1) integer pointer sizes may not be the same, this is the common case, and is cured by defining NULL as ((void*)0) and nil as ((id)0) instead of just 0, and is why Apple gets away with this usage, and I suspect the g++ magic __null takes care of this as well; 2) The standard actually allows different types of pointers to have different sizes, which I think is very rare, and certainly not the case on any architectures on which Cocoa does (or ever did) run--or any that I've ever worked with. Boolean negating a pointer is a hack that by happy coincidence works. No it is not; it is an explicitly designed and required feature of the language. a.) (int) NULL is NOT required or guaranteed 0x0 by the standard. Yes, it is. Obviously I overlooked that the standard guarantees the conversion NULL = int results in 0 and vice versa. OK, close but not quite. The standard says that NULL is 0, and that all pointer - int conversions take care of mapping the machine's null address to the integer 0, if necessary. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 10:40 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,21.08.2008 um 16:15 schrieb Michael Ash: On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote: Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier: Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin: Sometimes you see in source code something like this: if( booleanVarOrExpression == YES ) (I think, Rentzsch does it that way, IIRC) and Ithink, that this is simply correct. Oh, that is another discussion. Yeah, but connected It is antoher discussion in that way, that we have other types. (BOOL vs. type of logical expression in C) It is the same discussion in that way, that most programmers make some assumptions about the value (and the casting). (I bet, that 10 % believe, that the expression inside the if is typed BOOL) I'd be very surprised at this, given that BOOL is found only in Objective-C, and if statements are found in C. IIRC this depends on the concrete standard? No, it does not. Objective-C does not have a standard, and no C standard includes BOOL. Doing this is absolutly correct. BOOL var = …; // Something evaluating to YES or NO if( var == YES ) It's correct in that it is a legal language construct and it has well-defined results. But it is incorrect as far as doing what most people would want it to do. Consider this: BOOL var = 2; If somebody wants to do this, he does something wrong. 2 is no valid assignment for a BOOL. Of course it's valid: typedef signed char BOOL; The C standard guarantees that a signed char can hold at least values in the range of -127 to 127. Depending on the implementation, it may be abel to hold more. Thus any number in that range is a valid value for a variable of type BOOL. if(var == YES) That if statement will evaluate to false, even though the value of var is conceptually true. There is no conpetionally true. BOOL has the valid values YES and NO, not 2, not CONCEPTIONALLYYES. No, BOOL has the valid values -127 through 127, and possibly more. In the C language, all non-zero values are true. (True in C meaning anything that is not zero.) This is not a BOOL. *You* said, that there is no bool in C. No, I said that there is no BOOL in C. Of course it is also true that there is no bool in C. And it's true. But C does have the concept of logical truth and falsehood, it's just not expressed by means of a boolean type, or boolean values. An if takes no BOOL, but the type of an logical expression. There is no such thing in the C language as type of an logical expression. So I really can't tell what you're trying to say here, except that it must be wrong, because no such type exists. The if statement in C takes any scalar type as its conditional expression. For this reason, I recommend never comparing with YES. You should recommend, to assign never something else then YES or NO to a BOOL. *This* is wrong. Yes, I *also* recommend this. The two recommendations are not mutually exclusive. You should *never* assign anything besides YES or NO to your BOOL variables, and you should *never* compare any BOOL variable with YES. If you think that only one of these suggestions is sufficient, consider that Cocoa could easily return 2 from the -isEqual: method, for example. a simple BOOL var = …; // Something evaluating to YES or NO if( var ) is a very good hidden implicit cast from BOOL to logical expression. There is no hidden implicit cast. The if statement simply checks its contents for truth or falseness, No, it checks for == 0 or != 0. That's what I said. Truth in C is defined as != 0. Falseness is defined as == 0. BOOLs contain YES and NO. And any other value in the range of -127 to 127. BTW: This is an implicit cast, too: BOOL var = a b; because the result of the right expression types to logical expression, not to BOOL. No, the right side of the expression is typed *int*. There is no such C type as logical expression. You cannot use it explicitly, but it is a construction of the language. The check of if is on == 0 or != 0. This is less then an int (or whatever you use) and something else than a BOOL. No, there is no such construction of the language. The C if statement simply checks for equality to zero, period, full stop. There is no such concept as logical expression. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 8/20/08 11:06 PM, Michael Ash said:
It is a little known fact that when passing NULL (and by extension nil
or Nil) as a parameter to a vararg function, you *must* cast it to the
appropriate pointer type to guarantee correct behavior.
Interestingly, Apple's vararg methods which use nil as a terminator
(such as dictionaryWithObjectsAndKeys:) make no mention of this in
their documentation, and have a great deal of officially sanctioned
sample code which doesn't use such a cast. (And none of my code uses
it either.) I suppose Apple must be implicitly making a stronger
guarantee about the pointer-ness of nil than the C language makes
about NULL.
gcc provides:
-Wstrict-null-sentinel (C++ only)
Warn also about the use of an uncasted NULL as sentinel. When
compiling only with GCC this is a valid sentinel, as NULL is defined
to __null. Although it is a null pointer constant not a null pointer,
it is guaranteed to of the same size as a pointer. But this use is not
portable across different compilers.
and indeed:
--
#import Cocoa/Cocoa.h
int main(int argc, char *argv[])
{
NSArray* foo = [NSArray arrayWithObjects:@foo, @bar, nil];
return 0;
}
--
$ g++-4.2 -Wformat=2 -Wstrict-null-sentinel /Users/sean/Desktop/test.mm
/Users/sean/Desktop/test.mm:5: warning: missing sentinel in function call
using (id)nil in place of nil fixes the warning.
--
Sean McBride, B. Eng [EMAIL PROTECTED]
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Le 21 août 08 à 19:06, Scott Ribe a écrit : Wow, don't check the list for a few days and look what happens! After all, that's why nil (and Nil) exist at all, rather than just reusing NULL. Actually nil exists at all because Objective-C was created *before* NULL was in such standard use! (It may have always been part of stdio.h, don't recall for sure, but there definitely was no stddef.h.) Way back when, everybody defined their own macro, and some libraries even called it NIL or nil or null instead of NULL. (Others simply used 0.) I finally discovered that one of the headers in this old cross-platform code had defined NULL to be 0, just a plain integer 0, rather than (void *)0. Yes, that is allowed. In fact, Stroustrup suggests that it is preferred for C++, because stricter type checking makes ((void*)0) much less useful... GCC (actually g++) gets around this by providing __null, which is a magic token that gets special treatment from the compiler. If you look at stddef.h and/or _types.h, you'll see a special case for __GNUG__ (GNU C++) that defines NULL to be __null. It is a little known fact that when passing NULL (and by extension nil or Nil) as a parameter to a vararg function, you *must* cast it to the appropriate pointer type to guarantee correct behavior. 2 reasons: 1) integer pointer sizes may not be the same, this is the common case, and is cured by defining NULL as ((void*)0) and nil as ((id)0) instead of just 0, and is why Apple gets away with this usage, and I suspect the g++ magic __null takes care of this as well; 2) The standard actually allows different types of pointers to have different sizes, which I think is very rare, and certainly not the case on any architectures on which Cocoa does (or ever did) run--or any that I've ever worked with. Boolean negating a pointer is a hack that by happy coincidence works. No it is not; it is an explicitly designed and required feature of the language. a.) (int) NULL is NOT required or guaranteed 0x0 by the standard. Yes, it is. Obviously I overlooked that the standard guarantees the conversion NULL = int results in 0 and vice versa. OK, close but not quite. The standard says that NULL is 0, and that all pointer - int conversions take care of mapping the machine's null address to the integer 0, if necessary. Could you tell me which part of the standard states that NULL is 0. I don't managed to find it. The only relevant part I found about NULL is the section 7.17. Common definitions stddef.h : NULL which expands to an implementation-defined null pointer constant; ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 10:46 AM, Jean-Daniel Dupas [EMAIL PROTECTED] wrote: Le 21 août 08 à 19:06, Scott Ribe a écrit : Wow, don't check the list for a few days and look what happens! After all, that's why nil (and Nil) exist at all, rather than just reusing NULL. Actually nil exists at all because Objective-C was created *before* NULL was in such standard use! (It may have always been part of stdio.h, don't recall for sure, but there definitely was no stddef.h.) Way back when, everybody defined their own macro, and some libraries even called it NIL or nil or null instead of NULL. (Others simply used 0.) I finally discovered that one of the headers in this old cross-platform code had defined NULL to be 0, just a plain integer 0, rather than (void *)0. Yes, that is allowed. In fact, Stroustrup suggests that it is preferred for C++, because stricter type checking makes ((void*)0) much less useful... GCC (actually g++) gets around this by providing __null, which is a magic token that gets special treatment from the compiler. If you look at stddef.h and/or _types.h, you'll see a special case for __GNUG__ (GNU C++) that defines NULL to be __null. It is a little known fact that when passing NULL (and by extension nil or Nil) as a parameter to a vararg function, you *must* cast it to the appropriate pointer type to guarantee correct behavior. 2 reasons: 1) integer pointer sizes may not be the same, this is the common case, and is cured by defining NULL as ((void*)0) and nil as ((id)0) instead of just 0, and is why Apple gets away with this usage, and I suspect the g++ magic __null takes care of this as well; 2) The standard actually allows different types of pointers to have different sizes, which I think is very rare, and certainly not the case on any architectures on which Cocoa does (or ever did) run--or any that I've ever worked with. Boolean negating a pointer is a hack that by happy coincidence works. No it is not; it is an explicitly designed and required feature of the language. a.) (int) NULL is NOT required or guaranteed 0x0 by the standard. Yes, it is. Obviously I overlooked that the standard guarantees the conversion NULL = int results in 0 and vice versa. OK, close but not quite. The standard says that NULL is 0, and that all pointer - int conversions take care of mapping the machine's null address to the integer 0, if necessary. Could you tell me which part of the standard states that NULL is 0. NULL *can* be 0, it isn't *necessarily* 0 I don't managed to find it. The only relevant part I found about NULL is the section 7.17. Common definitions stddef.h : NULL which expands to an implementation-defined null pointer constant; ... and 0 is a valid null pointer constant. From 6.3.2.3: 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. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Could you tell me which part of the standard states that NULL is 0. NULL *can* be 0, it isn't *necessarily* 0 It follows from the rules re conversions that it must be either 0, or 0 cast to a pointer type. No value other than 0 is guaranteed to cast to the machine's actual null address (whatever bit pattern that might actually be). 6.3.2.3 which you quoted, does not provide for any value other than 0. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 11:56 AM, Scott Ribe [EMAIL PROTECTED] wrote: Could you tell me which part of the standard states that NULL is 0. NULL *can* be 0, it isn't *necessarily* 0 It follows from the rules re conversions that it must be either 0, or 0 cast to a pointer type. Or an implementation defined null pointer constant. That is, this is perfectly legal: #define NULL __builtin_special_null_keyword_that_is_specific_to_my_compiler as long as, when __builtin_special_null_keyword_that_is_specific_to_my_compiler is converted to a pointer type, it becomes a null pointer. GCC uses such an implementation defined constant to allow additional warnings when NULL is used in a non-pointer context (i.e. int i = 0;). No value other than 0 is guaranteed to cast to the machine's actual null address (whatever bit pattern that might actually be). 6.3.2.3 which you quoted, does not provide for any value other than 0. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 12:16 PM, Clark Cox [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 11:56 AM, Scott Ribe [EMAIL PROTECTED] wrote: Could you tell me which part of the standard states that NULL is 0. NULL *can* be 0, it isn't *necessarily* 0 It follows from the rules re conversions that it must be either 0, or 0 cast to a pointer type. Or an implementation defined null pointer constant. That is, this is perfectly legal: #define NULL __builtin_special_null_keyword_that_is_specific_to_my_compiler as long as, when __builtin_special_null_keyword_that_is_specific_to_my_compiler is converted to a pointer type, it becomes a null pointer. GCC uses such an implementation defined constant to allow additional warnings when NULL is used in a non-pointer context (i.e. int i = 0;). Arg, that example of a non-pointer context that GCC can warn about should have been (int i = NULL;) -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
as long as, when __builtin_special_null_keyword_that_is_specific_to_my_compiler is converted to a pointer type, it becomes a null pointer. And, if converted to integer type, it becomes 0. Right; I was certainly talking about standard integer/pointer types, without compiler magic, which must be 0, not any other value. Thing is, even the special compiler keyword is *indistinguishable* from 0, except for type checking rules. GCC uses such an implementation defined constant to allow additional warnings when NULL is used in a non-pointer context (i.e. int i = 0;). And also, I believe, to finesse away type conflicts in C++. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 21, 2008, at 3:54 AM, Jules Colding wrote: For that simple reason, I'd go for nil == foo every time. Yes, and in general you should always do if (CONSTANT == foo) to catch the potential if (CONSTANT = foo) error. If your name is Yoda, then perhaps if (3 != x) reads naturally to you. :-) As in most things, I think it is critical to strike a balance between code readability/skim-ability and other considerations. The previously mentioned warning will catch an unintentional assignment as long as you don't overzealously use extra sets of parenthesis. And to use Uli's example, the compiler will happily accept x =+ 5; even when that isn't what you intended. At the end of the day, you are responsible for what you typed, typos included. Jim ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 9:31 PM, Marcel Weiher wrote: I was swayed by the nil == foo arguments for a while, but my gut kept tugging at me and now I have switched back to just if ( !foo), or better (I prefer positive ifs), if (foo). Of course, if all the if (foo) is protecting is a message-send, you can just leave it out altogether and let nil do its thing to messages... For the sake of completeness (I know Marcel knows the rule), if you are using the return value of a message send, the value will be undefined depending on return type when sending a message to nil. See the runtime documentation for details. Jim ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 12:38 PM, Scott Ribe [EMAIL PROTECTED] wrote: as long as, when __builtin_special_null_keyword_that_is_specific_to_my_compiler is converted to a pointer type, it becomes a null pointer. And, if converted to integer type, it becomes 0. No, converting a pointer type (any pointer type, null or otherwise) results in implementation defined behavior or undefined behavior. From 6.3.2.3 6: Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type. That is, this always yields a null pointer to foo: foo *ptr = 0; This, on the other hand, is not guaranteed to yield zero (despite the fact that it does yield zero on most platforms) int i = (int)ptr; There is nothing preventing a compiler from compiling: int i = (int)NULL; to: int i = 42; Right; I was certainly talking about standard integer/pointer types, without compiler magic, which must be 0, not any other value. Thing is, even the special compiler keyword is *indistinguishable* from 0, except for type checking rules. It is distinguishable from 0, in that it is not guaranteed that you can convert it to an int. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 12:45 PM, Jim Correia [EMAIL PROTECTED] wrote: For the sake of completeness (I know Marcel knows the rule), if you are using the return value of a message send, the value will be undefined depending on return type when sending a message to nil. See the runtime documentation for details. As of the 10.5 runtime the zero value guarantee is more well defined (aka review the latest and prior documentation)... --- 10.5 --- - If the method returns an object, any pointer type, any integer scalar of size less than or equal to sizeof(void*), a float, a double, a long double, or a long long, then a message sent to nil returns 0. - If the method returns a struct, as defined by the Mac OS X ABI Function Call Guide to be returned in registers, then a message sent to nil returns 0.0 for every field in the data structure. Other struct data types will not be filled with zeros. - If the method returns anything other than the aforementioned value types the return value of a message sent to nil is undefined. --- older --- A message to nil also is valid, as long as the message returns an object, any pointer type, void, or any integer scalar of size less than or equal to sizeof(void*); if it does, a message sent to nil returns nil. If the message sent to nil returns anything other than the aforementioned value types (for example, if it returns any struct type, any floating-point type, or any vector type) the return value is undefined. You should therefore not rely on the return value of messages sent to nil unless the method's return type is an object, any pointer type, or any integer scalar of size less than or equal to sizeof(void*): -Shawn ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
You're forgetting that null pointers *must* convert to 0, this is why if(!foo) works. I think that would be the Except as previously specified.. part of what you quoted ;-) -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 1:23 PM, Scott Ribe [EMAIL PROTECTED] wrote: You're forgetting that null pointers *must* convert to 0, Please show me where that is guaranteed. this is why if(!foo) works. if(!foo) works because of: From 6.5.3.3: The expression !E is equivalent to (0==E). if(foo) works because of: From 6.8.4.1: In both forms, the first substatement is executed if the expression compares unequal to 0. Neither of these involves converting the pointer to an integer. I think that would be the Except as previously specified.. part of what you quoted ;-) -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Please show me where that is guaranteed. Well, you've really sent me on an archeological dig. It's not in the standard! I think there's an error of omission--yeah I know, claiming I'm not wrong, the standard is is quite the claim indeed, but bear with me a second: 6.3.2.3.5 covers integer - pointer, and says Except as previously specified... where that clearly refers to 6.3.2.3.3 converting integer constant 0 to null pointer. As I pointed out before, 6.3.2.3.6 covering pointer - integer says Except as previously specified... I assumed that referred to the requirement that null pointer - integer must yield 0, but a thorough search of the document reveals that *nothing* was previously specified. Clearly, an error in the standard--either of omission of whatever it was that was supposed to be previously specified, or of editing allowing that dangling reference. It's also not covered in either of the first 2 Corrigenda (I couldn't find the 3rd on the ISO site). Here's the history I have at hand: KR (2nd ed, 1988) -- A.6.6 ... An integral constant expression with the value 0... may be converted... to a pointer of any type. This produces a null pointer that is equal to a null pointer of the same type, but unequal to any pointer to a function or object. A pointer may be converted to an integral type large enough to hold it; the required size is implementation-dependent. The mapping function is also implementation-dependent. An object of integral type may be explicitly converted to a pointer. The mapping always carries a sufficiently wide integer converted from a pointer back to the same pointer, but is otherwise implementation-dependent. [Doesn't explicitly state it. But implies it because constant 0 - pointer and variable 0 - pointer really ought not produce different pointers, and constant 0 - pointer - integer variable really ought to produce 0.] Harbison Steele (5th ed, 2002) 6.2.3 ... When the source value is a pointer and the destination type is not _Bool, the pointer is treated as if it were an unsigned integer of a size equal to the size of the pointer. Then the unsigned integer is converted to the destination type using the rules listed before. If null pointers are not represented as the value 0, then they must be explicitly converted to 0 when converting the null pointer to an integer. [I suppose that's the reference I was remembering, since I did remember reading that explicitly stated in those ~words.] The Annotated C++ Reference Manual (1990) - 5.4 ... [Language is so similar to KR that it's not worth repeating...] The C++ Programming Language (Special Ed, 2000) --- [No information at all on pointer - integer conversions.] -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 3:19 PM, Scott Ribe [EMAIL PROTECTED] wrote: Please show me where that is guaranteed. Well, you've really sent me on an archeological dig. It's not in the standard! I think there's an error of omission--yeah I know, claiming I'm not wrong, the standard is is quite the claim indeed, but bear with me a second: 6.3.2.3.5 covers integer - pointer, and says Except as previously specified... where that clearly refers to 6.3.2.3.3 converting integer constant 0 to null pointer. Yes, but *only* a constant 0. The following is not guaranteed to set ptr to null: int i = 0; void *p = (void*)i; As I pointed out before, 6.3.2.3.6 covering pointer - integer says Except as previously specified... I assumed that referred to the requirement that null pointer - integer must yield 0, but a thorough search of the document reveals that *nothing* was previously specified. Clearly, an error in the standard--either of omission of whatever it was that was supposed to be previously specified, or of editing allowing that dangling reference. It is an intentional omission (I have had this argument before on comp.lang.c, except I was arguing your side at the time, and was set straight). For example, platforms with segmented memory models can have multiple different representations of null pointers, converting these back to int don't necessarily yield 0. This is allowed by the standard. Note, I'm not claiming that you can't convert a pointer to an integer, just that the mapping from pointer to an integer (of sufficient size) is implementation defined, and is not guaranteed to map null to zero. The only guarantee you have is that if you later convert that integer back to a pointer, it will compare equal to the original pointer. Of course, this is, for the most part, all academic, as any platforms on which Cocoa (or OpenStep APIs) exist all convert a null pointer to zero and vice-versa. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 21, 2008, at 3:42 PM, Jim Correia wrote: On Aug 21, 2008, at 3:54 AM, Jules Colding wrote: For that simple reason, I'd go for nil == foo every time. Yes, and in general you should always do if (CONSTANT == foo) to catch the potential if (CONSTANT = foo) error. If your name is Yoda, then perhaps if (3 != x) reads naturally to you. :-) As in most things, I think it is critical to strike a balance between code readability/skim-ability and other considerations. I keep changing my mind about this, so my code is inconsistent about it, but I've basically come to the same conclusion. One thing I've noticed is that I rarely get a bug due to misreading a boolean expression. More often I'm looking right at it (even if it's as unmistakeable as nil == obj) and I do the wrong thing anyway. Like I'll get the if-block and the else-block mixed up. It's like some kind of boolean-dyslexia in my brain. I find it helps to comment my logic. --Andy ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
It is an intentional omission (I have had this argument before on comp.lang.c, except I was arguing your side at the time, and was set straight). So, to be clear, there was at one time debate over whether null - integer yields 0 should be in the standard, and in the end that was intentionally omitted? So the error is in the editing--the stray except as previously specified was accidentally left in referring to nothing? Of course, this is, for the most part, all academic, as any platforms on which Cocoa (or OpenStep APIs) exist all convert a null pointer to zero and vice-versa. Yes. And the general evolution of things has been away from segmented/exotic addressing schemes to flat memory addressing. For good reasons, too ;-) -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 3:56 PM, Scott Ribe [EMAIL PROTECTED] wrote: It is an intentional omission (I have had this argument before on comp.lang.c, except I was arguing your side at the time, and was set straight). So, to be clear, there was at one time debate over whether null - integer yields 0 should be in the standard, and in the end that was intentionally omitted? As I understand it, yes (because, on platforms on which a null pointer is not all-bits-zero, people wanted to convert that pointer to the equivalent integer value).. So the error is in the editing--the stray except as previously specified was accidentally left in referring to nothing? The except as previously specified in 6.3.2.3 5 refers back to 6.3.2.3 3. Without the except as previously specified, 6.3.2.3 5 would directly contradict 6.3.2.3 3 (i.e. it would render the conversion from a null pointer constant to a null pointer undefined). Of course, this is, for the most part, all academic, as any platforms on which Cocoa (or OpenStep APIs) exist all convert a null pointer to zero and vice-versa. Yes. And the general evolution of things has been away from segmented/exotic addressing schemes to flat memory addressing. For good reasons, too ;-) Indeed :) -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
The except as previously specified in 6.3.2.3 5 refers back to 6.3.2.3 3. Without the except as previously specified, 6.3.2.3 5 would directly contradict 6.3.2.3 3 (i.e. it would render the conversion from a null pointer constant to a null pointer undefined). Right. But I'm talking about except as previously specified in 6.3.2.3 *6*, which refers to absolutely nothing. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cheap quality improvements (was Re: !foo vs foo == nil)
Speaking as a battle-hardened QA manager, the one simple step of turning on all warnings and removing them Absolutely. Which is why pointless warnings really annoy me! FYI, I'm not talking about Xcode/gcc here. I'm thinking of an old version of Watcom, in which a warning was generated for every case of a child class not overriding a descendant's virtual method! (Note: virtual, not pure virtual which of course was an error.) And these days I have loads of deprecated warnings that I won't be able to deal with for a while yet, which sometimes obscure useful warning about actual mistakes... Oh well... -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Thu, Aug 21, 2008 at 4:49 PM, Scott Ribe [EMAIL PROTECTED] wrote: The except as previously specified in 6.3.2.3 5 refers back to 6.3.2.3 3. Without the except as previously specified, 6.3.2.3 5 would directly contradict 6.3.2.3 3 (i.e. it would render the conversion from a null pointer constant to a null pointer undefined). Right. But I'm talking about except as previously specified in 6.3.2.3 *6*, which refers to absolutely nothing. From 6.3.1.2: 1 When any scalar value is converted to_Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1. _Bool is the one integer type that has a non implementation-defined conversion from pointer types. Without the except as previously specified, 6.3.1.2 1 and 6.3.2.3 6 would contradict each other. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
1 When any scalar value is converted to_Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1. Aaahhh... I looked and looked for the antecedent to that particular except as otherwise specified and couldn't find it. So C99 narrows the prior null pointer - 0 integral type requirement to only apply to conversions to the semi-obscure _Bool type. OK. I got it now ;-) -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
!foo vs foo == nil
This question has come up during the last CocoaHeads and no one was
really able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
char *p2 = NULL;
free(p1);
free(p2);
return 0;
}
if (toto)... just align your answer
On Wed, Aug 20, 2008 at 3:23 PM, Torsten Curdt [EMAIL PROTECTED] wrote:
This question has come up during the last CocoaHeads and no one was really
able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 21 Aug 2008, at 00:23, Torsten Curdt wrote:
This question has come up during the last CocoaHeads and no one was
really able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
Just try it out in a small project...
Keep in mind that Objective-C is the same as C, and C only checks for
numbers within the if() statement...
0 = false, 1 or more = true...
nil = 0 so, they mean the same thing...
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/filip%40code2develop.com
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 3:23 PM, Torsten Curdt wrote: This question has come up during the last CocoaHeads and no one was really able to give a definite answer. Do both expressions really mean the same thing (as nil is not null)? nil == 0. 0 is false, !0 is true. 0 == 0 is true. Therefore they are equivalent :). -- David Duncan Apple DTS Animation and Printing ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 3:32 PM, David Duncan [EMAIL PROTECTED] wrote: On Aug 20, 2008, at 3:23 PM, Torsten Curdt wrote: This question has come up during the last CocoaHeads and no one was really able to give a definite answer. Do both expressions really mean the same thing (as nil is not null)? nil == 0. 0 is false, !0 is true. 0 == 0 is true. Therefore they are equivalent :). no you failed, you are a lazy pointer :D -- David Duncan Apple DTS Animation and Printing ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com This email sent to [EMAIL PROTECTED] -- -mmw ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 21, 2008, at 00:30, Filip van der Meeren wrote:
On 21 Aug 2008, at 00:23, Torsten Curdt wrote:
This question has come up during the last CocoaHeads and no one was
really able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
Just try it out in a small project...
Keep in mind that Objective-C is the same as C, and C only checks
for numbers within the if() statement...
0 = false, 1 or more = true...
nil = 0 so, they mean the same thing...
I guess my questions wasn't phrased correctly. The point was more: is
'nil' really the equivalent of 0 or NULL.
There was a common perception that NULL is not really the same as nil.
But seems like in the end it really is (void*)0.
http://cocoawithlove.com/2008/06/doing-things-in-cocoa-with.html
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
hum (void *)0 is equal to 0 interesting...
type *ptr != type *ptr= NULL
you should also align your knowledge
you failed, you are a lazy pointer
On Wed, Aug 20, 2008 at 4:15 PM, Torsten Curdt [EMAIL PROTECTED] wrote:
On Aug 21, 2008, at 00:30, Filip van der Meeren wrote:
On 21 Aug 2008, at 00:23, Torsten Curdt wrote:
This question has come up during the last CocoaHeads and no one was
really able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
Just try it out in a small project...
Keep in mind that Objective-C is the same as C, and C only checks for
numbers within the if() statement...
0 = false, 1 or more = true...
nil = 0 so, they mean the same thing...
I guess my questions wasn't phrased correctly. The point was more: is 'nil'
really the equivalent of 0 or NULL.
There was a common perception that NULL is not really the same as nil. But
seems like in the end it really is (void*)0.
http://cocoawithlove.com/2008/06/doing-things-in-cocoa-with.html
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
and especially for someone who's developing in Java
On Wed, Aug 20, 2008 at 4:15 PM, Torsten Curdt [EMAIL PROTECTED] wrote:
On Aug 21, 2008, at 00:30, Filip van der Meeren wrote:
On 21 Aug 2008, at 00:23, Torsten Curdt wrote:
This question has come up during the last CocoaHeads and no one was
really able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
Just try it out in a small project...
Keep in mind that Objective-C is the same as C, and C only checks for
numbers within the if() statement...
0 = false, 1 or more = true...
nil = 0 so, they mean the same thing...
I guess my questions wasn't phrased correctly. The point was more: is 'nil'
really the equivalent of 0 or NULL.
There was a common perception that NULL is not really the same as nil. But
seems like in the end it really is (void*)0.
http://cocoawithlove.com/2008/06/doing-things-in-cocoa-with.html
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Just try it out in a small project... Keep in mind that Objective-C is the same as C, and C only checks for numbers within the if() statement... 0 = false, 1 or more = true... nil = 0 so, they mean the same thing... I guess my questions wasn't phrased correctly. The point was more: is 'nil' really the equivalent of 0 or NULL. There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. http://cocoawithlove.com/2008/06/doing-things-in-cocoa-with.html NULL is (void *)0. nil is (id)0. Use one for generic pointers and the other for objects to keep your mind sane. - jp smime.p7s Description: S/MIME cryptographic signature ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 6:15 PM, Torsten Curdt wrote: I guess my questions wasn't phrased correctly. The point was more: is 'nil' really the equivalent of 0 or NULL. Let's put it this way: freshly allocated objects have their memory zeroed out, except for their isa pointer. You can also rely on this meaning that any object pointer ivars you might have are nil. QED -Ken ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
#define __DARWIN_NULL ((void *)0)
#define nil __DARWIN_NULL
typedef struct objc_object {
Class isa;
} *id;
typedef id (*IMP)(id, SEL, ...);
id is a pointer you just demonstrated that 1 = 1
On Wed, Aug 20, 2008 at 4:42 PM, Jim Puls [EMAIL PROTECTED] wrote:
Just try it out in a small project...
Keep in mind that Objective-C is the same as C, and C only checks for
numbers within the if() statement...
0 = false, 1 or more = true...
nil = 0 so, they mean the same thing...
I guess my questions wasn't phrased correctly. The point was more: is
'nil' really the equivalent of 0 or NULL.
There was a common perception that NULL is not really the same as nil. But
seems like in the end it really is (void*)0.
http://cocoawithlove.com/2008/06/doing-things-in-cocoa-with.html
NULL is (void *)0.
nil is (id)0.
Use one for generic pointers and the other for objects to keep your mind
sane.
- jp
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. -jcr ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 7:15 PM, Torsten Curdt [EMAIL PROTECTED] wrote: I guess my questions wasn't phrased correctly. The point was more: is 'nil' really the equivalent of 0 or NULL. There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. As always, it's helpful to follow the rabbit down his hole and see where he goes. On stddef:403 we find this: #define NULL ((void *)0) So that's what NULL really is, at least on my system. Now, on objc/objc.h:57 we find this: #define nil __DARWIN_NULL /* id of Nil instance */ Well, we have to follow that a bit further. But here we are, on sys/_types.h:91: #define __DARWIN_NULL ((void *)0) So not only are NULL and nil equivalent, they are the *same thing*. (Now, they don't have to be. As I recall, NULL can just be a plain integer 0 as well. But they do have to be equivalent, and it just so happens that they are identical even though they don't need to be.) Now, that's not to say that they're semantically equivalent. NULL is meant to be any pointer type, whereas nil is meant to be for objects only (and Nil, capital N, is meant to be for the Class type). So it's best to keep that separation in your code to better indicate what's truly going on. After all, that's why nil (and Nil) exist at all, rather than just reusing NULL. But in the end they are ultimately the same. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 4:56 PM, John C. Randolph wrote: Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. There is a GCC warning to help you with that, but in addition, you can learn to type: if (nil == foo) Problem solved! :-) I personally much prefer to have if-statements that clearly evaluate to a boolean value. More intention revealing, and to me that's more important than being terse. j o a r ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
as Mike and me pointed NULL === NULL
but Im yet not alright with
(!foo) === if(foo == nil)
as I sent previously
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
char *p2 = NULL;
free(p1);
free(p2);
return 0;
}
On Wed, Aug 20, 2008 at 4:57 PM, Michael Ash [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 7:15 PM, Torsten Curdt [EMAIL PROTECTED] wrote:
I guess my questions wasn't phrased correctly. The point was more: is 'nil'
really the equivalent of 0 or NULL.
There was a common perception that NULL is not really the same as nil. But
seems like in the end it really is (void*)0.
As always, it's helpful to follow the rabbit down his hole and see
where he goes.
On stddef:403 we find this:
#define NULL ((void *)0)
So that's what NULL really is, at least on my system. Now, on
objc/objc.h:57 we find this:
#define nil __DARWIN_NULL /* id of Nil instance */
Well, we have to follow that a bit further. But here we are, on
sys/_types.h:91:
#define __DARWIN_NULL ((void *)0)
So not only are NULL and nil equivalent, they are the *same thing*.
(Now, they don't have to be. As I recall, NULL can just be a plain
integer 0 as well. But they do have to be equivalent, and it just so
happens that they are identical even though they don't need to be.)
Now, that's not to say that they're semantically equivalent. NULL is
meant to be any pointer type, whereas nil is meant to be for objects
only (and Nil, capital N, is meant to be for the Class type). So it's
best to keep that separation in your code to better indicate what's
truly going on. After all, that's why nil (and Nil) exist at all,
rather than just reusing NULL. But in the end they are ultimately the
same.
Mike
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 5:07 PM, mm w [EMAIL PROTECTED] wrote:
as Mike and me pointed NULL === NULL
but Im yet not alright with
(!foo) === if(foo == nil)
if(!foo) and if(foo == nil) are 100% identical as far as the language
is concerned. Trust me.
as I sent previously
How is this related to your question?
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
p1 is uninitialized, and has an indeterminate value...
char *p2 = NULL;
free(p1);
... so this free call is undefined behavior (and will likely crash)
free(p2);
return 0;
}
--
Clark S. Cox III
[EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
foo = -1
On Wed, Aug 20, 2008 at 5:19 PM, Clark Cox [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 5:07 PM, mm w [EMAIL PROTECTED] wrote:
as Mike and me pointed NULL === NULL
but Im yet not alright with
(!foo) === if(foo == nil)
if(!foo) and if(foo == nil) are 100% identical as far as the language
is concerned. Trust me.
as I sent previously
How is this related to your question?
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
p1 is uninitialized, and has an indeterminate value...
char *p2 = NULL;
free(p1);
... so this free call is undefined behavior (and will likely crash)
free(p2);
return 0;
}
--
Clark S. Cox III
[EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 7:07 PM, mm w wrote:
as Mike and me pointed NULL === NULL
but Im yet not alright with
(!foo) === if(foo == nil)
as I sent previously
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
char *p2 = NULL;
free(p1);
free(p2);
return 0;
}
You keep saying that, but what do you imagine it demonstrates?
-Ken
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 7:28 PM, mm w wrote: foo = -1 And? -Ken ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 4:57 PM, Michael Ash wrote: (Now, they don't have to be. As I recall, NULL can just be a plain integer 0 as well. But they do have to be equivalent, and it just so happens that they are identical even though they don't need to be.) Let me share a cautionary tale. At one point I was converting some Objective C code to be 64-bit ready, but for some reason it kept failing, in very strange ways. After much hunting, the problem turned out to be due to some old cross-platform code that the Objective C code linked against and imported headers from. I finally discovered that one of the headers in this old cross-platform code had defined NULL to be 0, just a plain integer 0, rather than (void *)0. Well, after all, zero is zero, how much difference can it make? Quite a bit, as it turns out, since in 64-bit one of them is four bytes of zero, and the other is eight bytes of zero. If you're just comparing against NULL, it doesn't matter, but if you're using it in something where size counts--say, a list of vararg arguments--then it matters a lot. It's not easy to debug, though, because who would think that you need to distinguish one NULL from another? I made sure that the definition of NULL from those cross-platform headers never made it in to my Objective C code, and all was fine. In Cocoa, NULL, nil, and Nil all should and must be pointer-sized zeros. By convention NULL is used for arbitrary pointers, nil for objects, and Nil for classes, and you should stick to that convention, even though it isn't strictly required by the language. Douglas Davidson ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 21, 2008, at 01:50, Ken Thomases wrote: On Aug 20, 2008, at 6:15 PM, Torsten Curdt wrote: I guess my questions wasn't phrased correctly. The point was more: is 'nil' really the equivalent of 0 or NULL. Let's put it this way: freshly allocated objects have their memory zeroed out, Why should that affect the pointer to an object? cheers -- Torsten ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 7:43 PM, Torsten Curdt wrote: On Aug 21, 2008, at 01:50, Ken Thomases wrote: On Aug 20, 2008, at 6:15 PM, Torsten Curdt wrote: I guess my questions wasn't phrased correctly. The point was more: is 'nil' really the equivalent of 0 or NULL. Let's put it this way: freshly allocated objects have their memory zeroed out, Why should that affect the pointer to an object? If you make a class with ivars which are object pointers, you are guaranteed by the runtime that they are zeroed out, which is to say nil, when an instance is allocated. I was pointing out that the runtime equates zeroing out the object's memory with guaranteeing that its object-pointer ivars are nil. From http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html#//apple_ref/doc/uid/TP40002974-CH4-DontLinkElementID_86 : An allocation message does other important things besides allocating memory: [...] It initializes all other instance variables to zero (or to the equivalent type for zero, such as nil, NULL, and 0.0). Right there is a guarantee that nil equals zero. Cheers, Ken ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
ok Im like a puppy I like to play, I will stop to play the evil
advogate for 98% of cases
here my late Initialization:
we can say (!toto) is the same of toto == NULL
but the Douglas pointed something really interesting... let see ahead
On Wed, Aug 20, 2008 at 5:39 PM, Andrew Merenbach
[EMAIL PROTECTED] wrote:
With all due respect, this seems a little more confusing than enlightening.
Alignment has little to do with the question, as far as I can see. Would
you be so kind as to explain what bearing your answer has on the original
poster's question?
-- Andrew
On Aug 20, 2008, at 3:29 PM, mm w wrote:
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
char *p2 = NULL;
free(p1);
free(p2);
return 0;
}
if (toto)... just align your answer
On Wed, Aug 20, 2008 at 3:23 PM, Torsten Curdt [EMAIL PROTECTED] wrote:
This question has come up during the last CocoaHeads and no one was
really
able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/andrew.merenbach%40ucla.edu
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 5:04 PM, j o a r wrote: On Aug 20, 2008, at 4:56 PM, John C. Randolph wrote: Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. There is a GCC warning to help you with that, but in addition, you can learn to type: if (nil == foo) Problem solved! :-) ...at the cost of five additional keystrokes, not to mention the aesthetics. -jcr ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
anyway I m going to add a hint
as a previous oppenant said yeh dude it's normal it's undefined/ nothin nada :)
int main(void) {g
char *p1;
char *p2 = NULL;
if(!p1)
puts(hello p1);
if(!p2)
puts(hello p2);
return 0;
}
output hello p2
On Wed, Aug 20, 2008 at 6:00 PM, mm w [EMAIL PROTECTED] wrote:
ok Im like a puppy I like to play, I will stop to play the evil
advogate for 98% of cases
here my late Initialization:
we can say (!toto) is the same of toto == NULL
but the Douglas pointed something really interesting... let see ahead
On Wed, Aug 20, 2008 at 5:39 PM, Andrew Merenbach
[EMAIL PROTECTED] wrote:
With all due respect, this seems a little more confusing than enlightening.
Alignment has little to do with the question, as far as I can see. Would
you be so kind as to explain what bearing your answer has on the original
poster's question?
-- Andrew
On Aug 20, 2008, at 3:29 PM, mm w wrote:
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
char *p2 = NULL;
free(p1);
free(p2);
return 0;
}
if (toto)... just align your answer
On Wed, Aug 20, 2008 at 3:23 PM, Torsten Curdt [EMAIL PROTECTED] wrote:
This question has come up during the last CocoaHeads and no one was
really
able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/andrew.merenbach%40ucla.edu
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 6:14 PM, John C. Randolph wrote: On Aug 20, 2008, at 5:04 PM, j o a r wrote: On Aug 20, 2008, at 4:56 PM, John C. Randolph wrote: Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. There is a GCC warning to help you with that, but in addition, you can learn to type: if (nil == foo) Problem solved! :-) ...at the cost of five additional keystrokes, not to mention the aesthetics. I was swayed by the nil == foo arguments for a while, but my gut kept tugging at me and now I have switched back to just if ( !foo), or better (I prefer positive ifs), if (foo). Of course, if all the if (foo) is protecting is a message-send, you can just leave it out altogether and let nil do its thing to messages... I think what my gut was trying to tell me is that I don't really care about the value of the pointer itself, that is only an implementation detail of object references. So not only is if (foo) more concise, it is actually more intention-revealing than if ( nil==foo ). Oh, and it slices and dices, too.. Marcel ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Aug 20, 2008, at 18:15, mm w wrote:
as a previous oppenant said yeh dude it's normal it's undefined/
nothin nada :)
int main(void) {g
char *p1;
char *p2 = NULL;
if(!p1)
puts(hello p1);
if(!p2)
puts(hello p2);
return 0;
}
output hello p2
I not sure of the state of computer science on planet Neptune, but
here on Earth we pretty much grasped the concept of an uninitialized
variable about 50 years ago.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Yes, nil is the equivalent of NULL and 0
nil is used for objective-c objects and NULL for C pointers
Regards
Vlad
On Aug 21, 2008, at 1:15 AM, Torsten Curdt wrote:
On Aug 21, 2008, at 00:30, Filip van der Meeren wrote:
On 21 Aug 2008, at 00:23, Torsten Curdt wrote:
This question has come up during the last CocoaHeads and no one
was really able to give a definite answer.
Do both expressions really mean the same thing (as nil is not null)?
if (!foo) {
...
}
if (foo == nil) {
...
}
Just try it out in a small project...
Keep in mind that Objective-C is the same as C, and C only checks
for numbers within the if() statement...
0 = false, 1 or more = true...
nil = 0 so, they mean the same thing...
I guess my questions wasn't phrased correctly. The point was more:
is 'nil' really the equivalent of 0 or NULL.
There was a common perception that NULL is not really the same as
nil. But seems like in the end it really is (void*)0.
http://cocoawithlove.com/2008/06/doing-things-in-cocoa-with.html
cheers
--
Torsten
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/falcon%40pravda.ru
This email sent to [EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
Using NULL would make your code easier to read, setting
a variable to NULL makes it obvious that a variable is a pointer,
at least in C, NULL does not have to be 0, 0 could be a valid pointer
value*, and NULL
some other invalid value, many people got in the habit of writing
if (!foo)
sure the compiler will automagically convert 0 in a pointer context to
an invalid pointer value,
plus preprocessor turns NULL back into 0 which is then recognized by the it
using NULL or nil (ObjC) is the recommended way, when referring to a pointer
for the tip an uninitialized variable is not really nothing
On Wed, Aug 20, 2008 at 6:50 PM, Quincey Morris
[EMAIL PROTECTED] wrote:
On Aug 20, 2008, at 18:15, mm w wrote:
as a previous oppenant said yeh dude it's normal it's undefined/ nothin
nada :)
int main(void) {g
char *p1;
char *p2 = NULL;
if(!p1)
puts(hello p1);
if(!p2)
puts(hello p2);
return 0;
}
output hello p2
I not sure of the state of computer science on planet Neptune, but here on
Earth we pretty much grasped the concept of an uninitialized variable about
50 years ago.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 7:56 PM, John C. Randolph [EMAIL PROTECTED] wrote: On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote: There was a common perception that NULL is not really the same as nil. But seems like in the end it really is (void*)0. They differ in type, not in value. NULL is (void *) 0. nil is (id) 0. Nil is (Class) 0. This is true conceptually but not as far as their actual definition. NULL can be either 0 or (void *)0. Nil and nil don't have a formal definition, as Objective-C lacks a formal specification, but on my machine they are both defined to be either 0 in 32-bit or (0L) in 64-bit. But for maximal clarity you should use them as you specify above. Personally, I prefer if (!foo) over if (foo == nil), because the latter has the hazard of a typo that compiles. You can lose a fair bit of time staring at if (foo = nil) before you spot the mistake. This hazard goes away if you turn on the appropriate warnings. I compile all of my code with -W -Wall -Wno-unused-parameter, and it has caught much more than just this error over the years. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson [EMAIL PROTECTED] wrote: Well, after all, zero is zero, how much difference can it make? Quite a bit, as it turns out, since in 64-bit one of them is four bytes of zero, and the other is eight bytes of zero. If you're just comparing against NULL, it doesn't matter, but if you're using it in something where size counts--say, a list of vararg arguments--then it matters a lot. It's not easy to debug, though, because who would think that you need to distinguish one NULL from another? It is a little known fact that when passing NULL (and by extension nil or Nil) as a parameter to a vararg function, you *must* cast it to the appropriate pointer type to guarantee correct behavior. Interestingly, Apple's vararg methods which use nil as a terminator (such as dictionaryWithObjectsAndKeys:) make no mention of this in their documentation, and have a great deal of officially sanctioned sample code which doesn't use such a cast. (And none of my code uses it either.) I suppose Apple must be implicitly making a stronger guarantee about the pointer-ness of nil than the C language makes about NULL. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 5:32 PM, mm w [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 5:19 PM, Clark Cox [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 5:07 PM, mm w [EMAIL PROTECTED] wrote:
as Mike and me pointed NULL === NULL
but Im yet not alright with
(!foo) === if(foo == nil)
if(!foo) and if(foo == nil) are 100% identical as far as the language
is concerned. Trust me.
as I sent previously
How is this related to your question?
#include stdio.h
#include stdlib.h
int main(void) {
char *p1;
p1 is uninitialized, and has an indeterminate value...
char *p2 = NULL;
free(p1);
... so this free call is undefined behavior (and will likely crash)
free(p2);
return 0;
}
--
Clark S. Cox III
[EMAIL PROTECTED]
haha gros malin why free (func) does this test?
arf sorry your trusting scale is going to zero
Not sure what you're trying to say. According to the C standard, given
a variable (foo) the following are identical:
if(foo == 0)
if(foo == nil)
if(foo == NULL)
if(!foo)
if(foo == '0')
and any other way you can compare to a literal zero.
--
Clark S. Cox III
[EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 7:44 PM, mm w [EMAIL PROTECTED] wrote: NULL does not have to be 0, 0 could be a valid pointer value This is not true, the C standard guarantees that 0, converted to any pointer type is a NULL pointer constant. It is not possible to convert 0 to a non-NULL pointer. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On 20 Aug 08, at 20:06, Michael Ash wrote: On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson [EMAIL PROTECTED] wrote: Well, after all, zero is zero, how much difference can it make? Quite a bit, as it turns out, since in 64-bit one of them is four bytes of zero, and the other is eight bytes of zero. If you're just comparing against NULL, it doesn't matter, but if you're using it in something where size counts--say, a list of vararg arguments--then it matters a lot. It's not easy to debug, though, because who would think that you need to distinguish one NULL from another? It is a little known fact that when passing NULL (and by extension nil or Nil) as a parameter to a vararg function, you *must* cast it to the appropriate pointer type to guarantee correct behavior. Source (and, preferably, example) please? A pointer is a pointer is a pointer; the internal representation of (char *) NULL is identical to (void *) NULL or (NSRect *) NULL or (id) nil or what-have-you. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 8:06 PM, Michael Ash [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson [EMAIL PROTECTED] wrote:
Well, after all, zero is zero, how much difference can it make? Quite a
bit, as it turns out, since in 64-bit one of them is four bytes of zero, and
the other is eight bytes of zero. If you're just comparing against NULL, it
doesn't matter, but if you're using it in something where size counts--say,
a list of vararg arguments--then it matters a lot. It's not easy to debug,
though, because who would think that you need to distinguish one NULL from
another?
It is a little known fact that when passing NULL (and by extension nil
or Nil) as a parameter to a vararg function, you *must* cast it to the
appropriate pointer type to guarantee correct behavior.
Interestingly, Apple's vararg methods which use nil as a terminator
(such as dictionaryWithObjectsAndKeys:) make no mention of this in
their documentation, and have a great deal of officially sanctioned
sample code which doesn't use such a cast. (And none of my code uses
it either.) I suppose Apple must be implicitly making a stronger
guarantee about the pointer-ness of nil than the C language makes
about NULL.
GCC does that for you (i.e. the NULL defined by GCC is already typed
to a pointer):
[EMAIL PROTECTED]:~]% cat test.c
#include stdio.h
int main() {
printf(sizeof(NULL) == %zu\n, sizeof(NULL));
return 0;
}
[EMAIL PROTECTED]:~]% cc test.c -arch i386 ./a.out
sizeof(NULL) == 4
[EMAIL PROTECTED]:~]% cc test.c -arch x86_64 ./a.out
sizeof(NULL) == 8
--
Clark S. Cox III
[EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
On Wed, Aug 20, 2008 at 8:31 PM, Andrew Farmer [EMAIL PROTECTED] wrote: On 20 Aug 08, at 20:06, Michael Ash wrote: On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson [EMAIL PROTECTED] wrote: Well, after all, zero is zero, how much difference can it make? Quite a bit, as it turns out, since in 64-bit one of them is four bytes of zero, and the other is eight bytes of zero. If you're just comparing against NULL, it doesn't matter, but if you're using it in something where size counts--say, a list of vararg arguments--then it matters a lot. It's not easy to debug, though, because who would think that you need to distinguish one NULL from another? It is a little known fact that when passing NULL (and by extension nil or Nil) as a parameter to a vararg function, you *must* cast it to the appropriate pointer type to guarantee correct behavior. Source (and, preferably, example) please? A pointer is a pointer is a pointer; the internal representation of (char *) NULL is identical to (void *) NULL or (NSRect *) NULL or (id) nil or what-have-you. The C standard doesn't require that NULL has a pointer type. The following is a perfectly valid definition of the NULL macro: #define NULL 0 If you pass that to a vararg function, it will be passed as if it were an int. From the C standard: An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. -- Clark S. Cox III [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
please, don't truncate my answer... especially * On Wed, Aug 20, 2008 at 8:27 PM, Clark Cox [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 7:44 PM, mm w [EMAIL PROTECTED] wrote: NULL does not have to be 0, 0 could be a valid pointer value This is not true, the C standard guarantees that 0, converted to any pointer type is a NULL pointer constant. It is not possible to convert 0 to a non-NULL pointer. -- Clark S. Cox III [EMAIL PROTECTED] -- -mmw ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
great alignement
On Wed, Aug 20, 2008 at 8:32 PM, Clark Cox [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 8:06 PM, Michael Ash [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson [EMAIL PROTECTED] wrote:
Well, after all, zero is zero, how much difference can it make? Quite a
bit, as it turns out, since in 64-bit one of them is four bytes of zero, and
the other is eight bytes of zero. If you're just comparing against NULL, it
doesn't matter, but if you're using it in something where size counts--say,
a list of vararg arguments--then it matters a lot. It's not easy to debug,
though, because who would think that you need to distinguish one NULL from
another?
It is a little known fact that when passing NULL (and by extension nil
or Nil) as a parameter to a vararg function, you *must* cast it to the
appropriate pointer type to guarantee correct behavior.
Interestingly, Apple's vararg methods which use nil as a terminator
(such as dictionaryWithObjectsAndKeys:) make no mention of this in
their documentation, and have a great deal of officially sanctioned
sample code which doesn't use such a cast. (And none of my code uses
it either.) I suppose Apple must be implicitly making a stronger
guarantee about the pointer-ness of nil than the C language makes
about NULL.
GCC does that for you (i.e. the NULL defined by GCC is already typed
to a pointer):
[EMAIL PROTECTED]:~]% cat test.c
#include stdio.h
int main() {
printf(sizeof(NULL) == %zu\n, sizeof(NULL));
return 0;
}
[EMAIL PROTECTED]:~]% cc test.c -arch i386 ./a.out
sizeof(NULL) == 4
[EMAIL PROTECTED]:~]% cc test.c -arch x86_64 ./a.out
sizeof(NULL) == 8
--
Clark S. Cox III
[EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: !foo vs foo == nil
I suspect that there is a language issue here. What exactly do you
mean by alignment?
On Wed, Aug 20, 2008 at 9:10 PM, mm w [EMAIL PROTECTED] wrote:
great alignement
On Wed, Aug 20, 2008 at 8:32 PM, Clark Cox [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 8:06 PM, Michael Ash [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson [EMAIL PROTECTED] wrote:
Well, after all, zero is zero, how much difference can it make? Quite a
bit, as it turns out, since in 64-bit one of them is four bytes of zero,
and
the other is eight bytes of zero. If you're just comparing against NULL,
it
doesn't matter, but if you're using it in something where size counts--say,
a list of vararg arguments--then it matters a lot. It's not easy to debug,
though, because who would think that you need to distinguish one NULL from
another?
It is a little known fact that when passing NULL (and by extension nil
or Nil) as a parameter to a vararg function, you *must* cast it to the
appropriate pointer type to guarantee correct behavior.
Interestingly, Apple's vararg methods which use nil as a terminator
(such as dictionaryWithObjectsAndKeys:) make no mention of this in
their documentation, and have a great deal of officially sanctioned
sample code which doesn't use such a cast. (And none of my code uses
it either.) I suppose Apple must be implicitly making a stronger
guarantee about the pointer-ness of nil than the C language makes
about NULL.
GCC does that for you (i.e. the NULL defined by GCC is already typed
to a pointer):
[EMAIL PROTECTED]:~]% cat test.c
#include stdio.h
int main() {
printf(sizeof(NULL) == %zu\n, sizeof(NULL));
return 0;
}
[EMAIL PROTECTED]:~]% cc test.c -arch i386 ./a.out
sizeof(NULL) == 4
[EMAIL PROTECTED]:~]% cc test.c -arch x86_64 ./a.out
sizeof(NULL) == 8
--
Clark S. Cox III
[EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/openspecies%40gmail.com
This email sent to [EMAIL PROTECTED]
--
-mmw
--
Clark S. Cox III
[EMAIL PROTECTED]
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
