Re: Mysterious crash with NSTableView

[Quincey Morris]

On Aug 27, 2016, at 13:55 , Andreas Falkenhahn  wrote:
> 
> I still don't know whether setting the delegate to nil
> before release is a general rule or does it only apply to NSTableView?

It’s not clear what delegate you mean by “button delegate”, but it doesn’t 
really matter. Delegates are not a special case of the rules, just a case where 
you need to pay attention to what the rules imply.

A “delegate” property is “strong”, “zeroing weak” or “unsafe”. (The terminology 
or syntax keyword for each of these has varied over time and context.) If it’s 
strong or zeroing-weak, there’s no need to set the property to nil. If it’s 
unsafe, you generally should set it to nil before you allow the lifetime of the 
delegate object to end.

Therefore, you can look in the API for the property — definitively, in the SDK 
you’re building against — and determine which of the above ownership types the 
property uses.

Note that you will see some inconsistencies in ownership types in different 
parts of Cocoa. That’s because the delegate pattern was standardized somewhere 
around 10.5, but older APIs may have been different and cannot be changed 
without breaking source and/or run-time compatibility.

There are a few real exceptions, which are historical relics, and documented (I 
think) in the ARC transition guide:

— ARC-compatible ownership rules are supported back to (something like) 10.5, 
but zeroing weak pointers weren’t supported until (IIRC) 10.6.8. In the 
interim, zero weak properties were actually unsafe.

— A very few classes (NSWindowController was one of them) did not support the 
zeroing weak mechanism (I mean pointers to objects of these classes, not 
references within these classes to objects of other classes). I believe these 
have all been corrected now, but you might need to be aware of which OS version 
they changed in, if you’re supporting older deployment targets. Or, avoid 
depending on the zeroing part of the behavior.

Incidentally, while it might be a noble goal to have your software support OS 
versions all the way back to 10.6 or 10.5, there are good reasons for moving on 
to later deployment targets. OS X really has gotten better over the years, and 
way-back support starts to become more a source of bugs than a source of 
compatibility.

Lastly, I may have lost track of things during the series of threads we’ve had 
about memory management in your app, but I can’t now understand why you don’t 
adopt ARC. I guess I thought it was because you were maintaining existing code, 
which presumably did its manual memory management properly. But if you’re 
writing new code, or even updating old code, there is literally no downside 
(AFAIK) in switching to ARC. Isn’t it a positive upside in source files shared 
between Mac and other platforms of your app, to not need retain and release 
calls? Note also that ARC and manual memory management can be intermixed in the 
same target freely (though not in the same source file), provided the existing 
manual memory management does follow the rules.

Since you’re not 100% familiar with the rules, why not just switch to ARC?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

Re: Mysterious crash with NSTableView

[Andreas Falkenhahn]

On 27.08.2016 at 18:10 Alex Zavatone wrote:

> Buuut, to the mind of the person learning this or trying to fit all
> the complexity of learning this in their head, it might be wise in
> the docs to remind the programmer that they need to do this and why
> with a, "just in case you are assuming that your code is ready to
> function now, please remember that the objects that end up making a
> working tableView require that the tableView's  dataSource object
> and delegate object need to be assigned, generally to the hosting
> view controller's instance of self. If this causes you to raise an
> eyebrow in confusion, the reasons why you must do this are xxx and
> .  Likewise upon deallocation of the tableView (if it gets
> called), these objects will need to be set to nil after  but
> before the tableView object is able to dispose of itself."

Huh? "Remember that you have to set this property to nil before you
release the object" would already be sufficient...

By the way, I still don't know whether setting the delegate to nil
before release is a general rule or does it only apply to NSTableView?
Should I also set my button delegates to nil before the buttons are
released?

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

Re: Mysterious crash with NSTableView

[Alex Zavatone]

Sent from my iPad. Please pardon typos.

On Aug 26, 2016, at 10:42 AM, Andreas Falkenhahn  wrote:

> On 26.08.2016 at 17:35 Gary L. Wade wrote:
> 
>> Try clearing your table view's data source and delegate before
>> releasing their object. It appears the pointer gets reassigned to an
>> NSRectSet before your table view completely goes away but after its delegate 
>> and data source have.
> 
> Great, that solves it. Thanks a lot!
> 
> But once again, I think it's a crime that there is no mentioning of this in 
> the class
> documentation of "setDelegate" and "setDatasource" :( 
> 

Agrees as it SHOULD be understood by the programmer as "well, that is simply 
how part of Objective-C works so I should EXPECT to have to set them."

Buuut, to the mind of the person learning this or trying to fit all the 
complexity of learning this in their head, it might be wise in the docs to 
remind the programmer that they need to do this and why with a, "just in case 
you are assuming that your code is ready to function now, please remember that 
the objects that end up making a working tableView require that the tableView's 
 dataSource object and delegate object need to be assigned, generally to the 
hosting view controller's instance of self. If this causes you to raise an 
eyebrow in confusion, the reasons why you must do this are xxx and .  
Likewise upon deallocation of the tableView (if it gets called), these objects 
will need to be set to nil after  but before the tableView object is able 
to dispose of itself."

Please feel free to use this as a running start on an addition to the docs that 
actually explains to the programmer how they will most likely set up their 
tableView.

- Alex Zavatone


> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

Re: Releasing properties?

[じょいすじょん]

> On 2016 Aug 27, at 23:31, Keary Suska  wrote:
> 
> 
>> On Aug 27, 2016, at 8:22 AM, じょいすじょん  
>> wrote:
>> 
>> 
>>> On 2016 Aug 27, at 23:09, Keary Suska  wrote:
>>> 
 
 On Aug 27, 2016, at 5:22 AM, Andreas Falkenhahn  
 wrote:
 
 Consider the following example properties:
 
  NSApplication: @property(strong) NSMenu *mainMenu
  NSFont: @property(readonly, copy) NSString *familyName
  NSColorPanel: @property(copy) NSColor *color
 
 AFAIU I must not release the NSMenu/NSString/NSColor obtained from these
 properties because I don't own the objects returned by those properties and
 Apple's memory management policy docs clearly say:
 
  "You must not relinquish ownership of an object you do not own"
 
 So I think I've got that right but I'd be glad if somebody could just
 confirm that I got it right ;)
 
 I'm just a little confused because of the keywords "strong" and "copy" in
 the @property declarations but AFAIU these only refer to setting those
 properties, not getting those properties, i.e. the object is copied when
 *setting* the property, not when *getting* it. Right?
 
 And another question: Can it also happen that a class has a property
 which returns an object which I *must* release or is it a general rule
 that getting a @property always returns objects which I do not own
 and hence mustn't released?
>>> 
>>> There are only specific method conventions that establish ownership: 
>>> alloc+init and new. This is because ownership should only be granted when 
>>> specifically requested by the caller. There is no good reason for an object 
>>> to require that a caller own a returned object. Now, some API could decide 
>>> to buck the convention and have a different object construction naming, but 
>>> the point is the same. If an API does anything else, it is badly designed. 
>>> Cocoa will never do this.
>>> 
>>> One could even argue (and some have) that there is no good reason for *any* 
>>> object method to return a retained object, as that forces the caller to 
>>> explicitly require ownership. And that is key: ownership is a function of 
>>> the caller, not the object.
>>> 
>>> HTH,
>>> 
>>> Keary Suska
>>> Esoteritech, Inc.
>>> "Demystifying technology for your home or business"
>>> 
>>> 
>> Just to keep everyone on the rules, I'm going to post the docs links.
>> It's too easy to quote it wrong. (not saying anybody did)
>> 
>> Objective-C
>> 
>> https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/MemoryManagement.html
>> 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html
>> 
>> Core Foundation (because you WILL use it at some point)
>> 
>> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html
> 
> Doh! Forgot “copy”. Best to point to docs since they are clear and succinct.
> 
Easy to mess up :)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

Re: Releasing properties?

[Keary Suska]

> On Aug 27, 2016, at 8:22 AM, じょいすじょん  
> wrote:
> 
> 
>> On 2016 Aug 27, at 23:09, Keary Suska  wrote:
>> 
>>> 
>>> On Aug 27, 2016, at 5:22 AM, Andreas Falkenhahn  
>>> wrote:
>>> 
>>> Consider the following example properties:
>>> 
>>>   NSApplication: @property(strong) NSMenu *mainMenu
>>>   NSFont: @property(readonly, copy) NSString *familyName
>>>   NSColorPanel: @property(copy) NSColor *color
>>> 
>>> AFAIU I must not release the NSMenu/NSString/NSColor obtained from these
>>> properties because I don't own the objects returned by those properties and
>>> Apple's memory management policy docs clearly say:
>>> 
>>>   "You must not relinquish ownership of an object you do not own"
>>> 
>>> So I think I've got that right but I'd be glad if somebody could just
>>> confirm that I got it right ;)
>>> 
>>> I'm just a little confused because of the keywords "strong" and "copy" in
>>> the @property declarations but AFAIU these only refer to setting those
>>> properties, not getting those properties, i.e. the object is copied when
>>> *setting* the property, not when *getting* it. Right?
>>> 
>>> And another question: Can it also happen that a class has a property
>>> which returns an object which I *must* release or is it a general rule
>>> that getting a @property always returns objects which I do not own
>>> and hence mustn't released?
>> 
>> There are only specific method conventions that establish ownership: 
>> alloc+init and new. This is because ownership should only be granted when 
>> specifically requested by the caller. There is no good reason for an object 
>> to require that a caller own a returned object. Now, some API could decide 
>> to buck the convention and have a different object construction naming, but 
>> the point is the same. If an API does anything else, it is badly designed. 
>> Cocoa will never do this.
>> 
>> One could even argue (and some have) that there is no good reason for *any* 
>> object method to return a retained object, as that forces the caller to 
>> explicitly require ownership. And that is key: ownership is a function of 
>> the caller, not the object.
>> 
>> HTH,
>> 
>> Keary Suska
>> Esoteritech, Inc.
>> "Demystifying technology for your home or business"
>> 
>> 
> Just to keep everyone on the rules, I'm going to post the docs links.
> It's too easy to quote it wrong. (not saying anybody did)
> 
> Objective-C
> 
> https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/MemoryManagement.html
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html
> 
> Core Foundation (because you WILL use it at some point)
> 
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html

Doh! Forgot “copy”. Best to point to docs since they are clear and succinct.

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


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

Re: Releasing properties?

[じょいすじょん]

> On 2016 Aug 27, at 23:09, Keary Suska  wrote:
> 
>> 
>> On Aug 27, 2016, at 5:22 AM, Andreas Falkenhahn  
>> wrote:
>> 
>> Consider the following example properties:
>> 
>>   NSApplication: @property(strong) NSMenu *mainMenu
>>   NSFont: @property(readonly, copy) NSString *familyName
>>   NSColorPanel: @property(copy) NSColor *color
>> 
>> AFAIU I must not release the NSMenu/NSString/NSColor obtained from these
>> properties because I don't own the objects returned by those properties and
>> Apple's memory management policy docs clearly say:
>> 
>>   "You must not relinquish ownership of an object you do not own"
>> 
>> So I think I've got that right but I'd be glad if somebody could just
>> confirm that I got it right ;)
>> 
>> I'm just a little confused because of the keywords "strong" and "copy" in
>> the @property declarations but AFAIU these only refer to setting those
>> properties, not getting those properties, i.e. the object is copied when
>> *setting* the property, not when *getting* it. Right?
>> 
>> And another question: Can it also happen that a class has a property
>> which returns an object which I *must* release or is it a general rule
>> that getting a @property always returns objects which I do not own
>> and hence mustn't released?
> 
> There are only specific method conventions that establish ownership: 
> alloc+init and new. This is because ownership should only be granted when 
> specifically requested by the caller. There is no good reason for an object 
> to require that a caller own a returned object. Now, some API could decide to 
> buck the convention and have a different object construction naming, but the 
> point is the same. If an API does anything else, it is badly designed. Cocoa 
> will never do this.
> 
> One could even argue (and some have) that there is no good reason for *any* 
> object method to return a retained object, as that forces the caller to 
> explicitly require ownership. And that is key: ownership is a function of the 
> caller, not the object.
> 
> HTH,
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
> 
Just to keep everyone on the rules, I'm going to post the docs links.
It's too easy to quote it wrong. (not saying anybody did)

Objective-C

https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/MemoryManagement.html

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html

Core Foundation (because you WILL use it at some point)

https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Releasing properties?

[Keary Suska]

> On Aug 27, 2016, at 5:22 AM, Andreas Falkenhahn  
> wrote:
> 
> Consider the following example properties:
> 
>NSApplication: @property(strong) NSMenu *mainMenu
>NSFont: @property(readonly, copy) NSString *familyName
>NSColorPanel: @property(copy) NSColor *color
> 
> AFAIU I must not release the NSMenu/NSString/NSColor obtained from these
> properties because I don't own the objects returned by those properties and
> Apple's memory management policy docs clearly say:
> 
>"You must not relinquish ownership of an object you do not own"
> 
> So I think I've got that right but I'd be glad if somebody could just
> confirm that I got it right ;)
> 
> I'm just a little confused because of the keywords "strong" and "copy" in
> the @property declarations but AFAIU these only refer to setting those
> properties, not getting those properties, i.e. the object is copied when
> *setting* the property, not when *getting* it. Right?
> 
> And another question: Can it also happen that a class has a property
> which returns an object which I *must* release or is it a general rule
> that getting a @property always returns objects which I do not own
> and hence mustn't released?

There are only specific method conventions that establish ownership: alloc+init 
and new. This is because ownership should only be granted when specifically 
requested by the caller. There is no good reason for an object to require that 
a caller own a returned object. Now, some API could decide to buck the 
convention and have a different object construction naming, but the point is 
the same. If an API does anything else, it is badly designed. Cocoa will never 
do this.

One could even argue (and some have) that there is no good reason for *any* 
object method to return a retained object, as that forces the caller to 
explicitly require ownership. And that is key: ownership is a function of the 
caller, not the object.

HTH,

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


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

Releasing properties?

[Andreas Falkenhahn]

Consider the following example properties:

NSApplication: @property(strong) NSMenu *mainMenu
NSFont: @property(readonly, copy) NSString *familyName
NSColorPanel: @property(copy) NSColor *color

AFAIU I must not release the NSMenu/NSString/NSColor obtained from these
properties because I don't own the objects returned by those properties and
Apple's memory management policy docs clearly say:

"You must not relinquish ownership of an object you do not own"

So I think I've got that right but I'd be glad if somebody could just
confirm that I got it right ;)

I'm just a little confused because of the keywords "strong" and "copy" in
the @property declarations but AFAIU these only refer to setting those
properties, not getting those properties, i.e. the object is copied when
*setting* the property, not when *getting* it. Right?

And another question: Can it also happen that a class has a property
which returns an object which I *must* release or is it a general rule
that getting a @property always returns objects which I do not own
and hence mustn't released?

Thanks!

-- 
Best regards,
 Andreas Falkenhahn  mailto:andr...@falkenhahn.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

[SOLVED] Re: length of file from NSFileHandle?

[Graham Cox]

> On 27 Aug 2016, at 1:41 PM, Ken Thomases  wrote:
> 
> The reason it has no length property is because not all NSFileHandles have 
> the concept of a length.  For example, a file handle associated with a pipe 
> or socket.

Right, though for those cases it could just return 0 or some other marker (or 
throw).

> For an on-disk file, you can seekToEndOfFile and get offsetInFile to 
> determine the file length.  If you need to not perturb the file position, you 
> can record the original offsetInFile and then seekToFileOffset:origOffset to 
> restore it after measuring the length.

After I posted I noticed that -seekToEndOfFile returns the length, and I was 
calling that anyway (to append to the file), so it was an obvious solution I’d 
missed.

> Matthew Emerson's suggestion of using fstat() with the fileDescriptor is also 
> reasonable.

I was about to head down that path when I noticed the above - thanks for the 
suggestions anyway, worth knowing for the future.

—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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

Re: Mysterious crash with NSTableView

[Greg Parker]

> On Aug 26, 2016, at 10:46 PM, Doug Hill  wrote:
> 
>> On Aug 26, 2016, at 9:20 PM, Jeff Szuhay  wrote:
>> 
 On Aug 26, 2016, at 8:44 PM, Sandor Szatmari 
  wrote:
 
 However, in your case I wonder what the static analyzer in Xcode tells you 
 about the bug you see?
>>> 
>>> I believe Andreas mentioned he does not use Xcode as his product is cross 
>>> platform, but this is a good suggestion.
>> 
>> Any why not? 
>> 
>> Sure, build it without Xcode, but couldn’t you create a shell project where 
>> the product doesn’t really matter, then build and use the tools in Xcode?
> 
> I believe you can also invoke the analyzer via the command-line tools.

If your build system runs from the command line and honors the CC and CXX 
environment variables then you may be able to use the scan-build tool to run 
the clang static analyzer.
http://clang-analyzer.llvm.org/scan-build.html


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



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

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

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