Amazon.com Widgets Any benefits of dealloc and re-alloc of origin compared to changing x and y?
Welcome, Guest. Please login or register.
Did you miss your activation email?
September 02, 2014, 04:45:14 PM
Home Help Search chat Login Register 
News: Read this please.The Great Kangaroo Escape Looking for reviews of the 4th ed on Amazon!   Twitter:  @skochan
                     

+ Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
|-+ Old Stuff
| |-+ Program Examples
| | |-+ Chapter 8
| | | |-+ Any benefits of dealloc and re-alloc of origin compared to changing x and y?
Pages: [1] Go Down
Print
Author Topic: Any benefits of dealloc and re-alloc of origin compared to changing x and y? (Read 1710 times)
mikerc
Newbie
*
Posts: 1






on: October 03, 2009, 12:35:34 PM

It would appear to me that there are not any obvious differences/benefits to either method.  Is there something not so obvious?


proposed setOrigin method of rectangle.m

-(void) setOrigin: (XYPoint *) pt
{
   if (! origin) // if origin has not been allocated yet do it now
      origin = [[XYPoint alloc] init];

   [origin setX: pt.x andY: pt.y];
}
Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #1 on: October 04, 2009, 01:59:02 PM

dealloc will be called when a Rectangle object needs to be destroyed.  At that time, you need to release the origin that was allocated by the setOrigin: method. 

Cheers,

Steve Kochan
Logged
ozmotion
Newbie
*
Posts: 3






Reply #2 on: January 28, 2010, 12:28:14 PM

Releasing origin when dealloc is called is one thing, but mikerc seemed to be asking whether there's any difference to the allocation (or not) of a new XYPoint whenever you want to change the coordinates of origin. If anything, it seems to me that it'd be more efficient to -not- re-allocate on change. Am i missing something?
Last Edit: January 28, 2010, 12:30:53 PM by ozmotion Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #3 on: January 28, 2010, 01:03:27 PM

Oh, I see that now.  An even better setOrigin: method would probably only just use the setX:andY: method to set the origin and you would override init to allocate the origin object whenever a new Rectangle object is created and initialized.

As an FYI, if you want to synthesize the setOrigin: method, you would want to use the copy property attribute (assign and retain won't do what you need).  That would end up requiring you to implement a copy method in your XYPoint class (described later in the book), which would in fact end up allocating a new XYPoint object.  That's why the setOrigin: method was developed this way in the text: to mimic the code that would be generated if you synthesized the setter using the copy attribute in the property declaration.

The bottom line here is that I would probably opt for implementing the setter as described in the first paragraph here and bypass synthesizing the setter.

Cheers,

Steve
Logged
Pages: [1] Go Up
Print
Jump to:



Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents (c) 2009 classroomM.com. All rights reserved.