On Dec 7, 2010, at 10:11 AM, Dennis wrote:
> On Dec 6, 2010, at 10:35 PM, Ken Thomases wrote:
>
>> If you step after the line "TileColumn *allColumns[boardDimension - 1]",
>> nothing has happened, yet. That's just a declaration.
>
> But if for example I declare int test[16], the debugger shows the array
> "test" with 16 members. That's not happening in the case of my code with
> allColumns. It's displaying an array of -1 members.
There is a big difference in declaring an array with an integer literal and
declaring one with an integer variable. In the former, the compiler knows at
compile time what is the size of the array. This is not so in the case of the
latter, which means that the debugger also doesn't know the size of the array.
A smarter debugger might be able to know this, but gdb is not a smarter
debugger. This is not a Cocoa thing; it's just part of the C language. In fact,
variable-length arrays weren't even supported in C until relatively recently
(C99?).
>> Finally, something to consider: there's nothing wrong with the technique
>> you've used of populating a C array and then building an NSArray from that C
>> array. However, you might consider creating an NSMutableArray that starts
>> empty and then, during the for loop, each TileColumn is added to it. If you
>> create the NSMutableArray with +arrayWithCapacity: or -initWithCapacity:,
>> you'll even avoid reallocation as you add elements to the array.
>
> I experimented with doing that unsuccessfully.
You should keep experimenting; using Foundation arrays is usually preferable to
using C arrays for most circumstances, unless speed is really important, and
you won't know if that's the case until you start profiling.
Anyway, this should get you going:
gameColumns = [[NSMutableArray alloc] initWithCapacity:boardDimension];
for (.....) {
[gameColumns addObject:[[[TileColumn alloc] init] autorelease];
}
Note the autorelease of the tilecolumn. You need this because NSMutableArrays
will claim ownership of their objects, so you need to relinquish your own
ownership or else you'll have a memory leak.
--
Dave Carrigan
d...@rudedog.org
Seattle, WA, 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
