In addition to what others have said...
On Aug 19, 2008, at 12:02 PM, Dave wrote:
[myPersonDetails setFirstName:[[NSString alloc] initWithCharacters:
myBufferPtr length: myStringSize]];
This makes memory management awkward. This code is creating an object
using alloc, so it's responsible for releasing it. However, you're
not keeping a pointer to the new string you've created. You're just
passing it to the PersonDetails object and then forgetting it. So,
you can't release it.
There are a few approaches to fixing this. First, you can use a local
variable to hold a pointer to the new object. Then, after passing it
to setFirstName: you can release it. Second, you can use alloc/init/
autorelease where you currently use alloc/init. Third, you can use a
convenience method which creates a string for you but doesn't leave
you responsible for releasing it, such as +stringWithCharacters:length:.
As noted by others, this requires that the firstName property of
PersonDetails be declared (and implemented, if you're not letting the
compiler synthesize it) to either "retain" or "copy" its value. If
the property doesn't do that, then it's failing to make sure the value
sticks around as long as it's needed.
//
// Do Stuff with myPersonDetails
//
//
// This is the second bit I am not sure of.
// Reset (free) the NSString Buffers
//
[myPersonDetails Reset];
myCount--;
}
My specific questions are:
Is the NSString allocation and initWithCharacters code the best way
to do this? If so, what would the setter look like in this case? If
not what is a better way of doing it?
in the: [myPersonDetails Reset]; method I was going to release all
the strings and zero out the integers. But I was wondering if it
would be better to allocate and release the object each time in the
while() loop. If I did this, would I need to define a release method
in myPersonDetails or would the standard method release the strings
for me?
The more normal way to do things is not to use objects as just dumb
containers. That is, it's not typical to reset an object and reuse it
with completely unrelated content.
Your mindset is reflected in the fact that you've named your class
PersonDetails rather than, say, Person. You're not conceiving of an
object with its own identity and responsibilities. You're just
thinking of it as a record or structure for holding some related data
together for a brief time. If that's what you need, then go for it,
but you needn't bother replacing working C code with an Objective-C
class.
If you do want to redesign in a more object-oriented fashion, then you
should probably initialize a Person object with its most salient
details at the time of its creation. For example, does it make sense
to ever have a person without a name? If not, then it shouldn't be
possible to create one that way. Similarly, it doesn't make sense to
reset a Person to have no name. When you're done with a given Person
object, you release it. If you need a new one, you allocate and
initialize a new one.
Lastly, if you need to do something with/to a Person, you should most
likely tell the Person object to do it. This is just a guess based on
what you've shown above, but I suspect you haven't given your
PersonDetails class much smarts about behavior. You probably just
have a bunch of code which queries PersonDetails objects for their
properties and then does all the work externally to the PersonDetails
class. A good guideline to follow is "Tell, Don't Ask" <http://www.pragprog.com/articles/tell-dont-ask
> (although it's not a hard-and-fast rule, and shouldn't be taken to
extremes).
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]
