Re: ARC vs Manual Reference Counting
Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. Alex Kac - President and Founder Web Information Solutions, Inc.___ 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: ARC vs Manual Reference Counting
On Sep 8, 2013, at 10:43 PM, Patrick Cusack wrote: > Apologies. I have no desire to start an internecine war. I have been reading > up on ARC for the past few hours. I also watched the WWDC video on ARC As with anything complex, it’ll take more than a few hours of reading/watching to get comfortable with it. > , and after having watched and read everything, I kept feeling as if I was > rather comfortable with the old manual memory model. Sure … so was I. But the switch was well worth it. > I guess my real question is "Why did Apple decide to introduce ARC at all?". > I am not convinced that the conventions are any easier than the previous > model of manual retain counts. They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. —Jens ___ 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: ARC vs Manual Reference Counting
Apologies. I have no desire to start an internecine war. I have been reading up on ARC for the past few hours. I also watched the WWDC video on ARC, and after having watched and read everything, I kept feeling as if I was rather comfortable with the old manual memory model. I guess my real question is "Why did Apple decide to introduce ARC at all?". I am not convinced that the conventions are any easier than the previous model of manual retain counts. Patrick On Sep 8, 2013, at 10:11 PM, Fritz Anderson wrote: > On Sun, Sep 8, 2013 at 11:41 PM, wrote: > Would anyone agree [with] me that ARC introduces more rules and > considerations than previously existed with manual reference counting? > > It's not clear which of the two messages, from the entire daily digest you > quoted, you are replying to. > > If you are asking for help of some kind, you might tell us what you need help > with, and how the documentation from Apple and clang.llvm.org have let you > down. > > If you have an observation to make, you should make it, rather than task > others to make theirs with no clue as to what you are driving at. What "rules > and considerations" are you talking about? It would help us, to know if > you've already pondered the thousands of words already published about the > rationale for introducing ARC, and the corner cases that remain; and, having > pondered them, what fresh rules and considerations you have discovered, or > how they might be more-clearly explained. > > Because you're not just inviting us to another religious war about issues > that were resolved (well or badly) years ago, are you? Your phrasing is > awfully close to "Let's you and him fight." > > — F > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Yes. I do. Absolutely. Sent from my iPad On Sep 8, 2013, at 9:41 PM, livinginlosange...@mac.com wrote: > Would anyone agree me that ARC introduces more rules and considerations than > previously existed with manual reference counting? ___ 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: ARC vs Manual Reference Counting
Converting to ARC in some ways - depends. On the whole we’re finding positives with it. Writing new apps with it its superb. On September 8, 2013 at 10:44:41 PM, livinginlosange...@mac.com (livinginlosange...@mac.com) wrote: Would anyone agree me that ARC introduces more rules and considerations than previously existed with manual reference counting? Alex Kac - President and Founder Web Information Solutions, Inc.___ 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
ARC vs Manual Reference Counting
Would anyone agree me that ARC introduces more rules and considerations than
previously existed with manual reference counting?
On Sep 8, 2013, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
> Send Cocoa-dev mailing list submissions to
> cocoa-dev@lists.apple.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.apple.com/mailman/listinfo/cocoa-dev
> or, via email, send a message with subject or body 'help' to
> cocoa-dev-requ...@lists.apple.com
>
> You can reach the person managing the list at
> cocoa-dev-ow...@lists.apple.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
>
>
> Today's Topics:
>
> 1. Evil setFrame: (Gerriet M. Denkmann)
> 2. Re: Evil setFrame: (Kyle Sluder)
>
>
> --
>
> Message: 1
> Date: Sun, 08 Sep 2013 11:36:08 +0700
> From: "Gerriet M. Denkmann"
> To: cocoa-dev@lists.apple.com
> Subject: Evil setFrame:
> Message-ID: <93387169-15d1-42a9-a1c0-fc516ffeb...@mdenkmann.de>
> Content-Type: text/plain; charset=utf-8
>
> I try to show a nib (which uses autolayout and which contains among other
> things a NewView inside an NSClipView inside an NSScrollView ) like this:
>
> if ( self.neuWindowController == nil )
> {
> // NewWindowController is subclass of NSWindowController
> self.neuWindowController = [ [NewWindowController alloc]
> initWithWindowNibName: @"SomeNib"
>
> eventsList:
> someArray
> ];
> };
>
> [ self.neuWindowController showWindow: nil ];
>
> The last line triggers in my NewView:
>
> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 bounds {{0, 0},
> {437, 252}}
> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 frame {{0, 0},
> {437, 252}}
> -[NewView resizeWithOldSuperviewSize:] NSClipView 0x10197b8e0 bounds {{0, 0},
> {398, 94}}
> -[NewView resizeWithOldSuperviewSize:] will call super with oldBoundsSize
> {437, 254}
> -[NewView setFrame:] will {{0, 0}, {0, 0}} ← why is super doing
> this to me ??
> -[NewView resizeWithOldSuperviewSize:] got frame {{0, 0}, {0, 0}}
>
> and from here on nothing works (not too surprising with such a small frame).
>
> Something must be terrible wrong in my setup of NewView, but what?
>
> Gerriet.
>
>
>
>
> --
>
> Message: 2
> Date: Sat, 07 Sep 2013 22:04:31 -0700
> From: Kyle Sluder
> To: "Gerriet M. Denkmann" ,
> cocoa-dev@lists.apple.com
> Subject: Re: Evil setFrame:
> Message-ID:
> <1378616671.3574.19245285.59d48...@webmail.messagingengine.com>
> Content-Type: text/plain; charset=utf-8
>
> On Sat, Sep 7, 2013, at 09:36 PM, Gerriet M. Denkmann wrote:
>> I try to show a nib (which uses autolayout and which contains among other
>> things a NewView inside an NSClipView inside an NSScrollView ) like this:
>>
>> if ( self.neuWindowController == nil )
>> {
>> // NewWindowController is subclass of NSWindowController
>> self.neuWindowController = [ [NewWindowController alloc]
>> initWithWindowNibName: @"SomeNib"
>>
>> eventsList:
>>someArray
>> ];
>> };
>>
>> [ self.neuWindowController showWindow: nil ];
>>
>> The last line triggers in my NewView:
>>
>> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 bounds {{0,
>> 0}, {437, 252}}
>> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 frame {{0,
>> 0}, {437, 252}}
>> -[NewView resizeWithOldSuperviewSize:] NSClipView 0x10197b8e0 bounds {{0,
>> 0}, {398, 94}}
>> -[NewView resizeWithOldSuperviewSize:] will call super with oldBoundsSize
>> {437, 254}
>> -[NewView setFrame:] will {{0, 0}, {0, 0}} ← why is super doing
>> this to me ??
>> -[NewView resizeWithOldSuperviewSize:] got frame {{0, 0}, {0, 0}}
>>
>> and from here on nothing works (not too surprising with such a small
>> frame).
>>
>> Something must be terrible wrong in my setup of NewView, but what?
>
> NewView lacks sufficient constraints to specify its size or position, to
> it is being resized to zero.
>
> I'm guessing NewView is the direct subview of the clip view? If so, you
> _MUST NOT_ change its translatesAutoresizingMaskIntoConstraints
> property, and you _MUST NOT_ try to control its size or position with
> constraints.
>
> I learned that the hard way over the course of several months. It's
> quite a pain in the ass, because a lot of constraints you'll naturally
> want to draw will be just as likely to affect the size of the scr
Re: Evil setFrame:
On 8 Sep 2013, at 12:04, Kyle Sluder wrote:
> On Sat, Sep 7, 2013, at 09:36 PM, Gerriet M. Denkmann wrote:
>> I try to show a nib (which uses autolayout and which contains among other
>> things a NewView inside an NSClipView inside an NSScrollView ) like this:
>>
>> if ( self.neuWindowController == nil )
>> {
>> // NewWindowController is subclass of NSWindowController
>> self.neuWindowController = [ [NewWindowController alloc]
>> initWithWindowNibName: @"SomeNib"
>>
>> eventsList:
>>someArray
>> ];
>> };
>>
>> [ self.neuWindowController showWindow: nil ];
>>
>> The last line triggers in my NewView:
>>
>> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 bounds {{0,
>> 0}, {437, 252}}
>> -[NewView resizeWithOldSuperviewSize:] NewView 0x101982430 frame {{0,
>> 0}, {437, 252}}
>> -[NewView resizeWithOldSuperviewSize:] NSClipView 0x10197b8e0 bounds {{0,
>> 0}, {398, 94}}
>> -[NewView resizeWithOldSuperviewSize:] will call super with oldBoundsSize
>> {437, 254}
>> -[NewView setFrame:] will {{0, 0}, {0, 0}} ← why is super doing
>> this to me ??
>> -[NewView resizeWithOldSuperviewSize:] got frame {{0, 0}, {0, 0}}
>>
>> and from here on nothing works (not too surprising with such a small
>> frame).
>>
>> Something must be terrible wrong in my setup of NewView, but what?
>
> NewView lacks sufficient constraints to specify its size or position, so it
> is being resized to zero.
>
> I'm guessing NewView is the direct subview of the clip view?
Yes, it is.
> If so, you _MUST NOT_ change its translatesAutoresizingMaskIntoConstraints
> property, and you _MUST NOT_ try to control its size or position with
> constraints.
Looking in Xcode I see that neither my NewView nor its superview (ClipView)
have any Constraints.
Of NewView I am told that: "The selected views have no constraints. At build
time explicit left, top, width, and height constraints will be generated for
the view."
The superview of the ClipView (ScrollView) has appropriate (and sufficient)
Constraints.
I just added in my NewView:
- (void)setFrame:(NSRect)frameRect
{
if ( frameRect.size.width > 0 && frameRect.size.height > 0 )
{
[ super setFrame: frameRect];
}
else
{
NSLog(@"%s will NOT call super for evil: %@",__FUNCTION__,
NSStringFromRect(frameRect));
}
}
Now everything seems to be ok.
These evil calls either result from [NSWindowController showWindow:] (three
times) or whenever I do -[NewView setFrameSize:].
In the latter case the backtrace looks like:
--- -[NewWindowController setStepper:] will setFrameSize {43347.463157723723,
242}
--- -[NewView setFrame:] will NOT call super for evil: {{0, 0}, {0, 0}}
(lldb) bt
frame #0: 0x000100045b89 EnTeP`-[NewView
setFrame:](self=0x00010a017e10, _cmd=0x7fff9216a551, frameRect=NSRect
at 0x7fff5fbfe080) + 153 at NewView.m:412
frame #1: 0x7fff91968e77 AppKit`-[NSView resizeWithOldSuperviewSize:] +
659
frame #2: 0x7fff91968307 AppKit`-[NSView resizeSubviewsWithOldSize:] +
318
frame #3: 0x7fff91914718 AppKit`-[NSView setFrameSize:] + 1101
frame #4: 0x7fff91969c81 AppKit`-[NSClipView setFrameSize:] + 394
frame #5: 0x7fff91913f5e AppKit`-[NSView setFrame:] + 299
frame #6: 0x7fff919d79ff AppKit`-[NSScrollView _setContentViewFrame:] +
596
frame #7: 0x7fff919d640a AppKit`-[NSScrollView tile] + 1863
frame #8: 0x7fff919d5c26 AppKit`-[NSScrollView _tileWithoutRecursing] +
49
frame #9: 0x7fff919d8b59 AppKit`-[NSScrollView
reflectScrolledClipView:] + 879
frame #10: 0x7fff919edebc AppKit`-[NSClipView
_reflectDocumentViewFrameChange] + 174
frame #11: 0x7fff9192a113 AppKit`-[NSView _postFrameChangeNotification]
+ 216
frame #12: 0x7fff91914813 AppKit`-[NSView setFrameSize:] + 1352
I do not understand why this happens, but at least I have a workaround. (10.8.4)
Kind regards
Gerriet.
___
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
