I'm trying to implement an n x n multidimensional array of ints in Objective-C, and because using NSMutableArray seems to be too much of an overhead I decided to implement it using only C's malloc and free. My question is, is the code below correct (no memory leaks) under ARC Objective-C?
#interface TwoDimensionalArray
{
int **array;
int size;
}
#end
#implementation TwoDimensionalArray
- (id)initWithSize: (int)s
{
if(self = [super init])
{
size = s;
array = malloc(sizeof(int*) * size);
for(int i = 0; i < size; i++)
{
array[i] = malloc(sizeof(int) * size);
for (int j = 0; j < size; j++)
{
array[i][j] = 0;
}
}
}
return self
}
- (id)init
{
return [self initWithSize:1];
}
- (void)dealloc
{
for(int i = 0; i < size; i++)
{
free(array[i]);
array[i] = nil;
}
free(array);
array = nil;
}
#end
If this is not correct, or if you think there is a definitely better way to do it in Objective-C without doing mallocs, please tell me. Thanks.
ARC implements automatic memory management for Objective-C objects and blocks, but does not
automate malloc/free.
(References: Clang/ARC documentation: General,
ARC Release Notes: FAQ.)
So your question is unrelated to ARC: Everything you malloc() must be
free()'d (and dealloc is good place to do so). From the first look your code looks OK.
(Small remarks: Zeroing the array pointers in dealloc is not necessary, but
NULL would be the appropriate pointer value to assign, nil is meant for Objective-C objects.)
I do not know how much overhead using Objective-C collections such as NSMutableArray
would cause, that should be tested (as already said in the comments) by profiling.
Related
I wonder is there any drawbacks when use alloc/free with pure C array inside Objective-C class?
For example:
#import "CVPatternGrid.h"
#implementation CVPatternGrid
#synthesize row = _row;
#synthesize column = _column;
#synthesize count = _count;
#synthesize score = _score;
- (id)initWithRow:(NSInteger)row column:(NSInteger)column {
if (self = [super init]) {
_grid = [self allocateNewGrid:row column:column];
}
return self;
}
- (NSInteger)moveCount {
return _count;
}
- (bool**)allocateNewGrid:(NSInteger)row column:(NSInteger)column {
bool **p = malloc(row * sizeof(bool*));
for (int i = 0; i < row; ++i) {
p[i] = malloc(column * sizeof(bool));
}
return p;
}
- (void)generateNewGrid:(NSInteger)row column:(NSInteger)column {
[self freeGrid];
_grid = [self allocateNewGrid:row column:column];
_count = [self.algorithmDelegate generateGrid:_grid];
_score = _count * 100;
}
- (BOOL)isMarkedAtRow:(NSInteger)row column:(NSInteger)column {
return YES;
}
- (void)freeGrid {
for (int i = 0; i < _row; ++i) {
free(_grid[i]);
}
free(_grid);
}
- (void)dealloc {
[self freeGrid];
}
#end
It's perfectly normal to use a C array in an Obj-C class. There are no low level data types in Obj-C — every class, including NSArray, NSString, etc, is using primitive C types internally.
However you are doing a few things wrong:
Do not use #synthesize unless you need to. In this case you don't need it, so delete those lines of code.
Do not use _foo to access variables unless you need it, again in this case you don't need it in any of your use cases (except, arguably, in your init and dealloc methods. But I would argue it should not even be used there. Other people disagree with me). My rule is to only use _foo when I run into performance issues when using self.foo syntax. There are also edge case issues such as KVO where you might run into problems when using an accessor inside init/dealloc. In the real world I have never run into any of those edge cases in more than 10 years of writing Obj-C — I always use accessors, unless they're too slow.
Some implementation details about how to declare an #property of a C array: Objective-C. Property for C array
I want to create a class that contains a dynamic, two-dimensional c-array of pointers to NSStrings. I know I can simulate a two-dimensional array using an NSArray containing multiple NSArrays, but if possible I'd like to do this using a traditional two-dimensional c-array. ARC won't allow a simple assignment of a pointer to an NSString to an element of a c-array unless you use "__unsafe_unretained":
#interface NumberStringsArray : NSObject
{
#public
NSString * __unsafe_unretained **_array;
}
To avoid memory leaks and to give an object in the class ownership of each NSString assigned to the c-array, I add a pointer to each NSString object to an NSMutableArray. In -(void)dealloc I free the memory acquired to create the two-dimensional c-array.
Here's my question: How do I declare a property based on the _array ivar so that I can refer to the i,j element of the array as "foobar.array[i][j]" rather than "foobar->array[i][j]"?
Later amplification: I did it in a very similar manner to the answerer except for the __bridge stuff. I don't know if that makes a difference. I allocate the two-dimensional array here:
self->_array = (NSString * __unsafe_unretained **)calloc(_columnCount, sizeof(void *));
if (!self->_array)
return nil;
for (UINT16 i = 0; i < _columnCount; i++)
{
self->_array[i] = (NSString * __unsafe_unretained *)calloc(_rowCount, sizeof(void *));
if (!self->_array[i])
{
for (UINT16 a = 0; a < _columnCount; a++)
if (self->_array[a])
free(self->_array[a]);
if (self->_array)
free(self->_array);
return nil;
}
}
I put pointers to the NSString objects into the array using substrings generated from a file of comma-separated values:
NSArray *numbers = [line componentsSeparatedByString: #","];
for (UINT16 i = 0; i < _columnCount; i++)
{
NSString *number = #"";
if (i < [numbers count])
number = [numbers objectAtIndex: i];
//
// save it in owners
//
[self.owners addObject: number];
self->_array[i][j] = number;
}
In -(void)dealloc I free all the memory:
-(void)dealloc
{
for (UINT16 i = 0; i < self.columnCount; i++)
if (self->_array[i])
free(self->_array[i]);
if (self->_array)
free(self->_array);
}
Declare this property:
#property (nonatomic) NSString * __unsafe_unretained **_array;
Then you can allocate the pointers to objects:
_array= (NSString * __unsafe_unretained **) malloc(M*sizeof(CFTypeRef) );
for(NSUInteger i=0; i<M;i++)
{
_array[i]= ((NSString * __unsafe_unretained *) malloc(N*sizeof(CFTypeRef) );
for(NSUInteger j=0; j<N;j++)
{
_array[i][j]= (__bridge NSString*) (__bridge_retained CFTypeRef) [[NSString alloc]initWithCString: "Hello" encoding: NSASCIIStringEncoding];
// I see that you got habit with C so you'll probably like this method
}
}
Then when you don't need it anymore, free the array:
for(NSUInteger i=0; i<M; i++)
{
for(NSUInteger j=0; j<N;j++)
{
CFTypeRef string=(__bridge_transfer CFTypeRef) _array[i][j];
}
free(_array[i]);
}
free(_array);
You can't because you can't declare a concrete object for an Objective-C class. So
NumberStringsArray object;
is not allowed.
You are forced to declare it as
NumberStringsArray *object = [[NumberStringsArray alloc] init.. ];
so you have to access to the ivar through the correct -> operator applied to pointers. Mind that the object.something in Objective-C is just a shorthand for [object something] while in standard C you would use . to access to fields of a concrete struct.
(Note: This addresses the creation/use of the property to access the data, not the way the data should be managed by conventional Objective-C storage management or by ARC. Thinking about that makes my head hurt.)
If you want a read-only C array to "look" like an Objective-C property, declare the property such as #property (readonly, nonatomic) char* myProp; and then, rather than using #synthesize, implement a getter for it along the lines of:
-(char**)myProp {
return myPropPointer;
// Or, if the array is allocated as a part of the instance --
return &myPropArray[0];
}
I have as property in a view, an array of array like this:
#interface MyView : UIView
#property (nonatomic) CGPoint **matrix;
#end
in the controller that own this view I have load the data in the -viewDidLoad and free memory in the -viewDidUnload like this:
- (void)viewDidLoad
{
self.myView.matrix = malloc(sizeof(CGPoint*) * array1Size);
for (int k = 0; k < array1Size; k++) {
self.myView.matrix[k] = malloc(sizeof(CGPoint) * innerArraySize);
}
}
- (void)viewDidUnload
{
for (int k = 0; k < array1Size; k++) {
free(self.myView.matrix[k]);
self.myView.matrix[k] = nil;
}
free(self.myView.matrix);
self.myView.matrix = nil;
[self setMyView:nil];
[super viewDidUnload];
}
While profiling I see a leak here. Can someone help me where I'm wrong?
thanks
update:
i try to remove free code from viewDidUnload and use dealloc like this:
-(void)dealloc {
[self freeArray];
}
- (void) freeArray {
for (int k = 0; k < 5; k++) {
free(self.myView.matrix[k]);
self.myView.matrix[k] = NULL;
}
free(self.myView.matrix);
self.myView.matrix = NULL;
}
then I embed init code in:
if (self.graphView.matrix == NULL) {
...
}
now no more leak, THANKS!
Your code does not make sure that each setup of the matrix is matched by exactly one tear down. For example, viewDidUnload is not guaranteed to be called. Also, you have no guards against duplicate setup or tear down.
If you really need the C array of arrays, a better approach would be to create it in the initializer of the view (initWithFrame: or initWithCoder:) and remove it in its dealloc.
Edit: To alleviate your concerns regarding dealloc and ARC:
You can certainly override dealloc in ARC and rely on it being called. The only difference is that you cannot explicitly call the overridden implementation ([super dealloc]). ARC will insert that for you.
Use an array of CGPoint:
#property (nonatomic) CGPoint *matrix;
.... init ...
{
...
matrix = (CGPoint*) malloc(arraySize * sizeof(CGPoint));
...
}
- (void) dealloc
{
free(matrix);
}
Then you simply set/get CGPoint structures directly in the array:
CGPoint someCGPoint = {0,0};
matrix[i] = someCGPoint;
someCGPoint = matrix[i];
That'll be faster and more memory efficient than CGPoint**. And your leak is gone.
I have seen this over and over, why exactly is it faster to use fast enumeration in loops rather than an NSEnumerator using nextObject:.
NSEnumerator is the old way to enumerate over collections. It involves creating an object to represent the enumeration, then calling a method on it for every single iteration. While this was perfectly serviceable for many years, it's not terribly efficient, as it involves at least one message send for every iteration of the loop. NSFastEnumeration is the more modern approach, which leverages native language support to provide a much more efficient enumeration. The way it works under the hood is it creates a struct that represents the current enumeration state and repeatedly calls -countByEnumeratingWithState:objects:count: on the collection. This method returns a C array of objects in the objects out-param as well as a counter in the count out-param. This allows the caller to then iterate over the C array. In essence, this means one message call per chunk of objects, which, depending on the collection, could be as efficient as a single message call to get all objects.
If you have a bit of code that looks like
for (id obj in myArray) {
[obj doSomething];
}
This gets translated by the compiler into something roughly equivalent to
NSFastEnumerationState __enumState = {0};
id __objects[MAX_STACKBUFF_SIZE];
NSUInteger __count;
while ((__count = [myArray countByEnumeratingWithState:&__enumState objects:__objects count:MAX_STACKBUFF_SIZE]) > 0) {
for (NSUInteger i = 0; i < __count; i++) {
id obj = __objects[i];
[obj doSomething];
}
}
The actual variables used are hidden, and the maximum size of the object buffer is also implementation-dependent, but the basic idea is there. It translates iteration over an obj-c collection into iteration over a C array.
GCC 8.9.4 Fast enumeration
protocol
GNUstep libs/base/trunk/Source/NSEnumerator.m countByEnumeratingWithState:objects:count:
It is not same as Apple's implementation but it is helpful to understand.
- (NSUInteger) countByEnumeratingWithState: (NSFastEnumerationState*)state
objects: (id*)stackbuf
count: (NSUInteger)len
{
IMP nextObject = [self methodForSelector: #selector(nextObject)];
int i;
state->itemsPtr = stackbuf;
state->mutationsPtr = (unsigned long*)self;
for (i = 0; i < len; i++)
{
id next = nextObject(self, #selector(nextObject));
if (nil == next)
{
return i;
}
*(stackbuf+i) = next;
}
return len;
}
NSArray *array = something;
array = { {1,2}, {2,3}, {3,4} }
that means array is an array of array. so how can you access all the arrays and their values.
we can use for loop like this
for (int i = 0; i < array.count; i++)
{
NSArray x = [array objectAtIndex:i];
}
or a fast enum works like this
for(NSArray array2 in array)
{
// do what ever you want with this new array2.
}
this is a sample example.
PS. I forgot how the array looks in console.
I'm trying to create a C array of objective C NSStrings using malloc. I'm not doing it right, but I don't think I'm far off. Maybe someone can point me in the right direction.
Let's say we want 5 strings in our array for the sake of argument.
Interface:
#interface someObject : NSObject {
NSString **ourArray;
}
#property () NSString **ourArray;
#end
Implementation:
#implementation someObject
#synthesize ourArray;
-(id)init {
if((self = [super init])) {
self->ourArray = malloc(5 * sizeof(NSString *));
}
return self;
}
-(NSString *)getStringAtPos3 {
if(self.ourArray[3] == nil) {
self.ourArray[3] = #"a string";
}
return self.ourArray[3];
}
#end
When I set a breakpoint in getStringAtPos3 it doesn't see the array element as nil so it never goes into the if statement.
mallocing an array of pointers is done as follows:
self->ourArray = malloc(5 * sizeof(NSString *));
if (self->ourArray == NULL)
/* handle error */
for (int i=0; i<5; i++)
self->ourArray[i] = nil;
malloc doesn't make guarantees about the contents of the returned buffer, so set everything to nil explicitly. calloc won't help you here, as a zero pattern and nil/NULL aren't the same thing.
Edit: even though zero and null may be the same on i386 and arm, they are not the same conceptually, just like NULL and nil are strictly not the same. Preferably, define something like
void *allocStringPtrs(size_t n)
{
void *p = malloc(sizeof(NSString *));
if (p == NULL)
// throw an exception
for (size_t i=0; i<n; i++)
p[i] = nil;
return p;
}
One issue is this:
self->ourArray = malloc(5 * sizeof(NSString *)); // notice the sizeof()
I figured out the problem - I should have been using calloc, not malloc. While malloc simply allocates the memory, calloc
contiguously allocates enough space for count objects that are size bytes of memory each and returns a pointer to the allocated memory. The allocated memory is filled with bytes of value zero.
This means you get an array of nil objects essentially as in objective c 0x0 is the nil object.