Re: NSRectArray by reference
Re: NSRectArray by reference
- Subject: Re: NSRectArray by reference
- From: Uli Kusterer <email@hidden>
- Date: Sun, 9 Sep 2007 23:28:52 +0200
On 09.09.2007, at 23:19, Brian Stern wrote:
* Use the NSArray solution that you have rejected. You didn't
mention how many rows there are but if it's less than say 100 there
will not be much overhead.
* Use an NSMutableData instance to hold the rects. There will be
less Obj-C overhead in this case than the NSArray solution.
* Make the data block that holds the NSRects a data member and make
the CalendarRowRects function a method. Reallocate the memory
block as required each time the CalendarRowRects method is called.
Release the memory block in your object's dealloc method. This has
the benefit of being very simple and straightforward and makes
memory errors unlikely. It will also have relatively low overhead.
There's always an option "D". Even when using bullet points in the
mistaken assumption that an option "D" can only exist when there are
options "A" through "C", and thus I could be prevented from claiming
there was an option "D". :-p
D) Create your own KDRectArray class that internally uses calloc()/
free() to create/dispose of its memory block, but wraps it all nicely
in an Objective C object that everyone can use, including indexed
accessors like:
-(NSRect) rectAtIndex: (unsigned)idx;
-(void) setRect: (NSRect)box atIndex: (unsigned)idx;
And you could even go overboard and provide objectAtIndex/
setObject:atIndex:, which would return an NSValue containing a rect
or whatever, and could be used with other classes that expect an
NSArray, not a KDRectArray. Well, if you're careful, at least.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden