Re: Who owns a child view controller?

2017-07-13 Thread Alex Zavatone 
One thing that I had to learn was to break my expectations of when a view 
controller (one that is tied to a navigationController) is deallocated.

My expectations initially were “oh, we’re closing it and going to another 
screen, it will just be deallocated.”  

Weee, no.  It’s part of a stack of view controllers if it’s in a navigation 
controller and the entire stack is what is needed for the user to be able to 
travel back and forth within the list of controllers that are “under” that nav 
controller.

I expect that if the app comes under memory pressure, the instantiated VCs will 
be faulted to disk and if even more pressure, they may be deallocated.  

But I’m not really sure about that.  

The one thing that I am aware of is that, “just because the user moves on to 
another view controller, that doesn’t mean that the one they left is 
deallocated.  I leave that to the OS to figure out.  If I have a set of view 
controllers that act as a module, I open a new storyboard, with a new nav 
controller, so that I when complete, I can close the whole thing by dismissing 
it and since there are no more references left, all the memory for the whole 
section is just returned as everything deallocates.  This approach has worked 
worked pretty well for me for about 4 years now in iOS.  It’s not applicable 
everywhere though.

Cheers,
Alex Zavatone

> On Jul 13, 2017, at 4:57 AM, Jeremy Hughes  
> wrote:
> 
>> On 13 Jul 2017, at 01:32, Jens Alfke  wrote:
>> 
>>> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes  
>>> wrote:
>>> 
>>> I’m trying to understand memory management so I can avoid retain cycles and 
>>> other issues.
>> 
>> That’s fine. But using a weak reference to try to detect when an object gets 
>> dealloced is fraught with peril, viz. this entire thread :)
> 
> That was some test code I wrote to investigate a situation I noticed while 
> debugging. The actual issue is whether an object (view controller) is 
> deallocated rather than when it is deallocated.
> 
>> On 13 Jul 2017, at 01:32, Jens Alfke  wrote:
>> 
>> If you want to find out if your code is leaking by creating reference 
>> cycles, just run it and ask either Instruments or Xcode to find leaks.
> 
> I was hoping to avoid creating cycles in the first place...
> 
>> On 13 Jul 2017, at 00:15, Quincey Morris 
>>  wrote:
>> 
>> I may be overlooking something important, but I see basically three tasks 
>> you need to handle to avoid memory management bugs:
>> 
>> 1. Strong references.
>> 
>> 2. Weak references.
>> 
>> 3. Unowned/unsafe references.
> 
> I’ve abbreviated this summary - but the things that I find confusing are:
> 
> 1. When to use unowned rather than weak. I’ve read Apple’s Swift book and 
> other discussions, and one explanation I found is that unowned is a bit like 
> forced unwrapping - you can (or should) use it when you’re sure that the 
> reference will always be valid, and it saves you from having to use an 
> optional. According to Greg Parker’s email there is also unsafe unretained 
> which is different from unowned. I think that unsafe unretained is the same 
> as unowned(unsafe) in Swift, but I could be wrong.
> 
> There is a thread on Stack Overflow where people are confused about the 
> difference between unowned and unowned(unsafe).
> 
> https://stackoverflow.com/questions/26553924/what-is-the-difference-in-swift-between-unownedsafe-and-unownedunsafe
> 
> According to a comment from Dave Abrahams (who I think works at Apple):
> 
> "unowned and unowned(safe) do incur reference counting cost—that is the cost 
> of safety, and why even make unowned(unsafe) available otherwise?—and it’s 
> currently worse than regular strong reference counting cost because ARC isn’t 
> optimizing for it. Neither throws an exception; they trap when misused, 
> permanently stopping the program”
> 
> But if unowned is a synonym for unowned(safe), I’m not sure what “Neither” 
> means in the last sentence - is he talking about safe and unsafe unowned, or 
> just unsafe unowned?
> 
> Apple’s Swift book says:
> 
> "The examples above show how to use safe unowned references. Swift also 
> provides unsafe unowned references for cases where you need to disable 
> runtime safety checks—for example, for performance reasons. As with all 
> unsafe operations, you take on the responsiblity for checking that code for 
> safety.
> 
> "You indicate an unsafe unowned reference by writing unowned(unsafe). If you 
> try to access an unsafe unowned reference after the instance that it refers 
> to is deallocated, your program will try to access the memory location where 
> the instance used to be, which is an unsafe operation.”
> 
> At this point I’m pretty confused about the difference between strong and 
> safe unowned. I understand that strong retains its reference, but it seems to 
> me that Dave Abrahams and Apple’s Swift

Re: NSAccessibility

2017-07-13 Thread Quincey Morris 
On Jul 13, 2017, at 10:17 , Tom Doan  wrote:
> 
> it looks like NSAccessibilityStaticText was added with 10.10.
> 
> My problem is that setAccessibilityElement is never called explicitly by 
> SCIContentView

That seems to make it a bug in Scintilla. Does it actually support macOS prior 
to 10.10? (Its web site is unclear on this point.)

Looking at the documentation of “NSAccessibilityStaticText”, you’re probably 
supposed to override its methods explicitly in your subclass. You might be able 
to work around the problem by explicitly implementing all 3 methods, and 
invoking super only if you’re running on 10.10+.

But I don’t like your chances, if Scintilla isn’t checking its version numbers 
properly.

___

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: Who owns a child view controller?

2017-07-13 Thread Quincey Morris 
On Jul 13, 2017, at 02:57 , Jeremy Hughes  wrote:
> 
> When to use unowned rather than weak

Here’s how I understand the situation in Swift. As usual, I may have some 
things a bit wrong, but I think this is right. There are four kinds of 
reference variable (or stored property) in Swift:

1. Strong.

2. Weak.

3. Unowned(safe), usually abbreviated to just “unowned”.

4. Unowned(unsafe).

Note that these are attributes of the variable (i.e. storage location), not the 
reference (i.e. pointer). It’s easy to forget that and talk about “strong 
references” for example, but technically there’s no such thing.


“Strong” means that the variable retains its reference. No surprises here.

All of the other cases do *not* retain their reference. That is, they do not 
increment the object’s retain count. But there are other things going on that 
account for the differences between them.

“Weak” means the reference is optional, can be nil, and is automatically set to 
nil if the referenced object is deallocated. This is safe, because you can’t 
end up trying to follow an invalid pointer: Swift guarantees that you will see 
a valid pointer or nil. The downside of “weak” is that a side-table of non-nil 
weak variable addresses is maintained somewhere, so that weak variables can be 
nil'ed on deallocation of the referenced object. There is some performance 
overhead to this, especially as there must obviously be some kind of locking 
mechanism to provide thread safety.

“Unowned” means that the reference is non-optional and can persist after the 
referenced object is deallocated. This avoids the performance penalty of 
“weak”, but can’t provide a validity guarantee for the pointer — it’s up to you 
to keep the object alive for as long as you use the unowned variable’s 
reference. The clever part, which is specific to Swift, is that objects 
secretly have *another* retain count, which is the number of *unowned* variable 
references to the object. An object is not actually deallocated until *both* 
retain counts go to zero — at which point there are obviously no references to 
it any more. If you try to use an unowned variable reference while the *main* 
reference count is zero and the *unowned* reference count is non-zero, you are 
trying to use a zombie object and your app will immediately crash.

Think about this. In effect, all Swift apps have zombie checking on all the 
time. It’s impossible to use a reference to a non-alive object, and it’s 
impossible for a stale pointer to refer to an instance of a different class 
(which can happen in Obj-C if memory is re-allocated for another object while 
you still hold a pointer to it.) It’s a simple but brilliant idea. It’s pretty 
cheap, and it crashes as early as possible, which makes debugging easier. What 
Dave meant, in the things you quoted, is that there’s an overhead to this.  
Aside from questions of optimization, the overhead is similar to “strong” 
retain counting.

“Unowned(unsafe)” means the same thing as “unretained unsafe” in Obj-C. It’s 
just a pointer, and you’re responsible for knowing it’s safe to use at any 
given time. Obviously, you’d like never to see one of these in Swift code.


The usage rules for these things are pretty straightforward to state, even 
though it might be harder in particular cases to be sure what to use.

For owning variables, use strong. By default, use weak the rest of the time. If 
you can reason that a non-owning variable is going to contain a valid reference 
once initially set (like a “parent” reference in a child object to which the 
parent has an owning reference in its “children” array, or like an IBOutlet 
reference, usually), you can avoid the overhead of “weak” and use “unowned” 
instead. (IIRC, you *must* declare a weak variable as optional, you *must not* 
declare an unowned variable as optional, but you can declare *either* as 
implicitly unwrapped optional.)

In general, don’t use “unowned(unsafe)”. You should only see it in legacy APIs 
in the SDKs, where for historical reasons it can’t be declared more 
definitively as something safer. You might occasionally use it in your own code 
if the secondary reference counting of “unowned(safe)” happens to be a 
performance problem.

___

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

NSAccessibility

2017-07-13 Thread Tom Doan 
I have a program which uses the Scintilla text editor. When it's run on an OS 
10.8, it gets a crash due to an 
unrecognized selector for setAccessibilityElement (part of log shown at the 
bottom).

The interface for the view that causes the problem is:

@interface SCIContentView : NSView <
  NSTextInputClient,
  NSUserInterfaceValidations,
  NSDraggingSource,
  NSDraggingDestination,
  NSAccessibilityStaticText>;

where it looks like NSAccessibilityStaticText was added with 10.10.

My problem is that setAccessibilityElement is never called explicitly by 
SCIContentView so I don't know how 
to prevent this call from being made. Any suggestions?

Best regards,

Tom Doan
Estima


Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
reason: '-[SCIContentView setAccessibilityElement:]: unrecognized selector sent 
to instance 0x7fcbac051ba0'
terminate called throwing an exception
abort() called

Application Specific Backtrace 1:
0   CoreFoundation  0x7fff85469b06 
__exceptionPreprocess 
+ 198
1   libobjc.A.dylib 0x7fff8b7033f0 objc_exception_throw 
+ 43
2   CoreFoundation  0x7fff8550040a -[NSObject(NSObject) 
doesNotRecognizeSelector:] + 186
3   CoreFoundation  0x7fff8545802e ___forwarding___ + 
414
4   CoreFoundation  0x7fff85457e18 
_CF_forwarding_prep_0 
+ 232
5   RATS0x000101b2786a -[SCIContentView 
initWithFrame:] + 266
6   RATS0x000101b2ac05 -[ScintillaView 
initWithFrame:] + 197


---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

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: Question about structs and enum placement in a project

2017-07-13 Thread Eric E. Dolecki 
I've broken out a folder "Structs and Enums" with sub-folders based on
related areas of operation. I'm currently prototyping so I don't have tons
and tons of operation types. Seems good enough, adds organization, and it
keeps my classes much cleaner. I will probably end up with less than a
dozen of each in total.

On Thu, Jul 13, 2017 at 9:56 AM Igor Ranieri Elland  wrote:

> If they’re not being declared inside another object, why not put them in
> their own files?
>
>
> > Am 13.07.2017 um 15:53 schrieb Eric E. Dolecki :
> >
> > Perhaps. Then maybe a folder of categorized structs and enums? I
> personally
> > dislike seeing them sprinkled throughout AppDelegate & other classes.
> It's
> > easy to cntrl-click to where they are defined, but it seems like a lot of
> > clutter.
> >
> > On Thu, Jul 13, 2017 at 9:52 AM Charles Srstka  >
> > wrote:
> >
> >> For a project of any appreciable size, that’s gonna be one huge file…
> >>
> >> Charles
> >>
> >>> On Jul 13, 2017, at 8:37 AM, Eric E. Dolecki 
> wrote:
> >>>
> >>> I am planning on putting all my structs and enums into it's own swift
> >> file
> >>> - to keep my project cleaner. Seems safe enough, thoughts on this?
> >>>
> >>> Thanks,
> >>> Eric
> >>> ___
> >>>
> >>> 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/cocoadev%40charlessoft.com
> >>>
> >>> This email sent to cocoa...@charlessoft.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/igor%40elland.me
> >
> > This email sent to i...@elland.me
>
>
___

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: Question about structs and enum placement in a project

2017-07-13 Thread Igor Ranieri Elland 
If they’re not being declared inside another object, why not put them in their 
own files?


> Am 13.07.2017 um 15:53 schrieb Eric E. Dolecki :
> 
> Perhaps. Then maybe a folder of categorized structs and enums? I personally
> dislike seeing them sprinkled throughout AppDelegate & other classes. It's
> easy to cntrl-click to where they are defined, but it seems like a lot of
> clutter.
> 
> On Thu, Jul 13, 2017 at 9:52 AM Charles Srstka 
> wrote:
> 
>> For a project of any appreciable size, that’s gonna be one huge file…
>> 
>> Charles
>> 
>>> On Jul 13, 2017, at 8:37 AM, Eric E. Dolecki  wrote:
>>> 
>>> I am planning on putting all my structs and enums into it's own swift
>> file
>>> - to keep my project cleaner. Seems safe enough, thoughts on this?
>>> 
>>> Thanks,
>>> Eric
>>> ___
>>> 
>>> 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/cocoadev%40charlessoft.com
>>> 
>>> This email sent to cocoa...@charlessoft.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/igor%40elland.me
> 
> This email sent to i...@elland.me

___

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: Question about structs and enum placement in a project

2017-07-13 Thread Charles Srstka 
Folders are good. I’d avoid glomming too many types into one file, because 
you’ll spend a lot of time scrolling through that file looking for things. 
Better to break things into smaller files where possible.

Charles

> On Jul 13, 2017, at 8:53 AM, Eric E. Dolecki  wrote:
> 
> Perhaps. Then maybe a folder of categorized structs and enums? I personally 
> dislike seeing them sprinkled throughout AppDelegate & other classes. It's 
> easy to cntrl-click to where they are defined, but it seems like a lot of 
> clutter.
> 
> On Thu, Jul 13, 2017 at 9:52 AM Charles Srstka  > wrote:
> For a project of any appreciable size, that’s gonna be one huge file…
> 
> Charles
> 
> > On Jul 13, 2017, at 8:37 AM, Eric E. Dolecki  > > wrote:
> >
> > I am planning on putting all my structs and enums into it's own swift file
> > - to keep my project cleaner. Seems safe enough, thoughts on this?
> >
> > Thanks,
> > Eric
> > ___
> >
> > 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/cocoadev%40charlessoft.com
> >  
> > 
> >
> > This email sent to cocoa...@charlessoft.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: Question about structs and enum placement in a project

2017-07-13 Thread Eric E. Dolecki 
Perhaps. Then maybe a folder of categorized structs and enums? I personally
dislike seeing them sprinkled throughout AppDelegate & other classes. It's
easy to cntrl-click to where they are defined, but it seems like a lot of
clutter.

On Thu, Jul 13, 2017 at 9:52 AM Charles Srstka 
wrote:

> For a project of any appreciable size, that’s gonna be one huge file…
>
> Charles
>
> > On Jul 13, 2017, at 8:37 AM, Eric E. Dolecki  wrote:
> >
> > I am planning on putting all my structs and enums into it's own swift
> file
> > - to keep my project cleaner. Seems safe enough, thoughts on this?
> >
> > Thanks,
> > Eric
> > ___
> >
> > 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/cocoadev%40charlessoft.com
> >
> > This email sent to cocoa...@charlessoft.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: Question about structs and enum placement in a project

2017-07-13 Thread Charles Srstka 
For a project of any appreciable size, that’s gonna be one huge file…

Charles

> On Jul 13, 2017, at 8:37 AM, Eric E. Dolecki  wrote:
> 
> I am planning on putting all my structs and enums into it's own swift file
> - to keep my project cleaner. Seems safe enough, thoughts on this?
> 
> Thanks,
> Eric
> ___
> 
> 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/cocoadev%40charlessoft.com
> 
> This email sent to cocoa...@charlessoft.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: Who owns a child view controller?

2017-07-13 Thread Charles Srstka 
> On Jul 12, 2017, at 6:30 PM, Quincey Morris 
>  wrote:
> 
> On Jul 12, 2017, at 16:19 , Greg Parker  > wrote:
>> 
>> "Unowned" means something else in Swift.
> 
> I suppose. I guess I’ve internalized “unowned” to mean “unretained but 
> crashes tidily” in Swift, but “unretained and crashes as messily as possible” 
> in Obj-C. :) Plus, Swift has “unowned(unsafe)” which means the same thing as 
> “unretained unsafe” in Obj-C.
> 
> (And, yes, I know that Swift “unowned” isn’t precisely unretained. Whoever 
> thought of this trick should get a round of applause.)
> 
> But you drove to me to look at the NSWindow documentation, and it appears 
> that the “delegate” property is (now) weak, not unsafe unretained. I’m not 
> sure when this changed.


It’s in the 10.13 release notes, so whether it’s actually changed yet is up to 
interpretation. ;-)

Charles

___

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

Question about structs and enum placement in a project

2017-07-13 Thread Eric E. Dolecki 
I am planning on putting all my structs and enums into it's own swift file
- to keep my project cleaner. Seems safe enough, thoughts on this?

Thanks,
Eric
___

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: Who owns a child view controller?

2017-07-13 Thread Jeremy Hughes 
> On 13 Jul 2017, at 11:26, Jeremy Hughes  wrote:
> 
> So perhaps the difference between safe and unsafe unowned is that safe 
> unowned generates a runtime error (but doesn’t crash) while unsafe unowned 
> crashes? Or perhaps they both crash, but unowned(unsafe) gives a more helpful 
> error message?

Here’s some playground code:

import Foundation

class Element
{
var name = "name"
}

var element1: Element? = Element()

unowned var element2 = element1!

element1 = nil

var element3 = element2

When Xcode (8.2.1) doesn’t crash (which seems to happen quite frequently with 
playgrounds) I get the following error:

Execution was interrupted, reason: EXC_BREAKPOINT (code=EXC_I386_BPT, 
subcode=0x0).

If I change unowned to unowned(unsafe) I sometimes get a more informative error:

Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x20).

EXC_BAD_ACCESS is more informative than EXC_BREAKPOINT because it’s obviously a 
memory error.

But sometimes I don’t get an error.

By inference, unowned is safer than unowned(unsafe) because it crashes 
predictably. But this is tangential to other memory questions because I’m not 
planning to use unowned(unsafe) in my own code.

Jeremy

___

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: Who owns a child view controller?

2017-07-13 Thread Jeremy Hughes 
> On 13 Jul 2017, at 10:57, Jeremy Hughes  wrote:
> 
> Apple’s Swift book says:
> 
> "The examples above show how to use safe unowned references. Swift also 
> provides unsafe unowned references for cases where you need to disable 
> runtime safety checks—for example, for performance reasons. As with all 
> unsafe operations, you take on the responsiblity for checking that code for 
> safety.
> 
> "You indicate an unsafe unowned reference by writing unowned(unsafe). If you 
> try to access an unsafe unowned reference after the instance that it refers 
> to is deallocated, your program will try to access the memory location where 
> the instance used to be, which is an unsafe operation.”
> 
> At this point I’m pretty confused about the difference between strong and 
> safe unowned. I understand that strong retains its reference, but it seems to 
> me that Dave Abrahams and Apple’s Swift book are saying or implying that 
> (safe) unowned also retains its reference - so the consequence of using 
> (safe) unowned incorrectly is that it will create a retain cycle, whereas 
> using unowned(unsafe) incorrectly will crash. But if unowned(safe) retains 
> its reference, how is it different from strong (apart from whether ARC is 
> currently optimising for it)?

That last paragraph is wrong, since the Swift book also says:

"IMPORTANT
Use an unowned reference only when you are sure that the reference always 
refers to an instance that has not been deallocated.
If you try to access the value of an unowned reference after that instance has 
been deallocated, you’ll get a runtime error.”

So perhaps the difference between safe and unsafe unowned is that safe unowned 
generates a runtime error (but doesn’t crash) while unsafe unowned crashes? Or 
perhaps they both crash, but unowned(unsafe) gives a more helpful error message?

Jeremy

___

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: Who owns a child view controller?

2017-07-13 Thread Jeremy Hughes 
> On 13 Jul 2017, at 01:32, Jens Alfke  wrote:
> 
>> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes  
>> wrote:
>> 
>> I’m trying to understand memory management so I can avoid retain cycles and 
>> other issues.
> 
> That’s fine. But using a weak reference to try to detect when an object gets 
> dealloced is fraught with peril, viz. this entire thread :)

That was some test code I wrote to investigate a situation I noticed while 
debugging. The actual issue is whether an object (view controller) is 
deallocated rather than when it is deallocated.

> On 13 Jul 2017, at 01:32, Jens Alfke  wrote:
> 
> If you want to find out if your code is leaking by creating reference cycles, 
> just run it and ask either Instruments or Xcode to find leaks.

I was hoping to avoid creating cycles in the first place...

> On 13 Jul 2017, at 00:15, Quincey Morris 
>  wrote:
> 
> I may be overlooking something important, but I see basically three tasks you 
> need to handle to avoid memory management bugs:
> 
> 1. Strong references.
> 
> 2. Weak references.
> 
> 3. Unowned/unsafe references.

I’ve abbreviated this summary - but the things that I find confusing are:

1. When to use unowned rather than weak. I’ve read Apple’s Swift book and other 
discussions, and one explanation I found is that unowned is a bit like forced 
unwrapping - you can (or should) use it when you’re sure that the reference 
will always be valid, and it saves you from having to use an optional. 
According to Greg Parker’s email there is also unsafe unretained which is 
different from unowned. I think that unsafe unretained is the same as 
unowned(unsafe) in Swift, but I could be wrong.

There is a thread on Stack Overflow where people are confused about the 
difference between unowned and unowned(unsafe).

https://stackoverflow.com/questions/26553924/what-is-the-difference-in-swift-between-unownedsafe-and-unownedunsafe

According to a comment from Dave Abrahams (who I think works at Apple):

"unowned and unowned(safe) do incur reference counting cost—that is the cost of 
safety, and why even make unowned(unsafe) available otherwise?—and it’s 
currently worse than regular strong reference counting cost because ARC isn’t 
optimizing for it. Neither throws an exception; they trap when misused, 
permanently stopping the program”

But if unowned is a synonym for unowned(safe), I’m not sure what “Neither” 
means in the last sentence - is he talking about safe and unsafe unowned, or 
just unsafe unowned?

Apple’s Swift book says:

"The examples above show how to use safe unowned references. Swift also 
provides unsafe unowned references for cases where you need to disable runtime 
safety checks—for example, for performance reasons. As with all unsafe 
operations, you take on the responsiblity for checking that code for safety.

"You indicate an unsafe unowned reference by writing unowned(unsafe). If you 
try to access an unsafe unowned reference after the instance that it refers to 
is deallocated, your program will try to access the memory location where the 
instance used to be, which is an unsafe operation.”

At this point I’m pretty confused about the difference between strong and safe 
unowned. I understand that strong retains its reference, but it seems to me 
that Dave Abrahams and Apple’s Swift book are saying or implying that (safe) 
unowned also retains its reference - so the consequence of using (safe) unowned 
incorrectly is that it will create a retain cycle, whereas using 
unowned(unsafe) incorrectly will crash. But if unowned(safe) retains its 
reference, how is it different from strong (apart from whether ARC is currently 
optimising for it)?

2. When to use weak or unowned in closure capture lists (rather than default to 
strong) is also pretty confusing! Presumably the default strong option is 
correct for some or most closures, but I don’t have a very clear idea of when 
it’s not correct.

3. Whether (and when) it’s necessary to avoid using functions or class 
variables whose name begins with new or copy. I don’t think this is discussed 
in Apple’s Swift book (or I haven’t found where it’s discussed), but I think 
it’s necessary for classes that interface with Objective C in some way (e.g. 
subclasses of Cocoa classes).

My experience of memory management in Objective-C and Swift (after many years 
of experience with C and C++) is that it mostly “just works” (as Apple say in 
the Swift book) - but there are many cases where you need a deeper 
understanding and it’s hard to find clear explanations.

Jeremy




___

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: