Question

I’ve been banging my head against this problem all day, I would be very grateful to anyone who could help out.

Here’s the deal – I’m trying to create a dynamic C array using malloc(). This array will hold CGPoint structs, which I start building and assigning right after the array is built. Here’s the code:

CGPoint* tempVertices = malloc(sizeof(CGPoint) * 4);  //defining a collision frame
tempVertices[0] = CGPointMake(37, 46);
tempVertices[1] = CGPointMake(69, 40);
tempVertices[2] = CGPointMake(48, 6);
tempVertices[3] = CGPointMake(17, 10);

//Then I pass the pointer to my array off to a setter...
[self setVertices: tempVertices];

However, when tempVertices gets created, it seems that I’m only getting space for one CGPoint:

int test1 = sizeof(CGPoint);        // 8
int test2 = sizeof(tempVertices);   // 4
int test3 = sizeof(*tempVertices);  // 8

When stepping through with the XCode debugger, it shows that tempVertices is a pointer to a CGPoint. When I set tempVertices[0], the CGPoint that tempVertices points to recieves that value, which is reflected in the debugger. Where did my other 3 slots go? tempVertices seems to be pointing to a singe CGPoint instead of an array. I want the array.

Any ideas on what I’m doing wrong? I know that there are other ways to fix this using C++ or other objects, but I want to stick to C if possible.

Thanks in advance!

---

Update :

To answer zpasternack, setVertices: is a custom written setter. And I don’t know how / if it knows how big the incoming array is. I’m trying to understand straight C stuff better, so insights/explanations regarding the proper way of passing a dynamic C-array as an argument are highly appreciated. Here’s what the setter looks like :

- (void) setVertices:(CGPoint*) val {
    _vertices = val;    //_vertices is a member variable of the type CGPoint* 
    //...calculate a centroid, other stuff...
}

If needed, I could wrap my CGPoints in NSValue objects and use an NSArray instead, but I sure would like to know the right way of doing it in plain ol’ C.

Thanks to everyone who has commented – you guys are great 🙂

Answer 1

OK, after your edit I think I see what’s going on. That code, exactly as you’ve written, should work OK. Xcode won’t show you the values of any of those CGPoints, because it doesn’t know it’s an array, just a pointer to a single CGPoint. But it’s there. Set a breakpoint right after you call setVertices:. At the gdb prompt, print some of those values.

(gdb) print _vertices[1]
$2 = {
  x = 69, 
  y = 40
}
(gdb) print _vertices[3]
$3 = {
  x = 17, 
  y = 10
}

Correct, see?

That’s not to say there aren’t issues here. For one thing, setVertices: is leaking that memory. You’re allocating memory for tempVertices, holding onto that pointer, but not freeing it anywhere. The next time you call setVertices:, you’ll have a leak.

A bigger issue is that nobody knows how many CGPoints are in that array, except the code that allocated the memory for it. Will it always be 4 CGPoints? What happens if somebody accesses _vertices[5] or _vertices[27]? Bad things, if you didn’t allocate that much space for them.

Is there a requirement that this be a plain C array? Like, these points are going to get passed to OpenGL or cocos2d or something? If not, you might consider using some kind of array class for it. Because these aren’t NSObject-derived objects you’re storing, you can’t use an NSArray. You could use a std::vector, if you don’t mind dragging in a buncha C++. I probably would not do that.

If you’re set on sticking with a C array, you should probably do some work to try to make the interface less error prone. Like I mentioned before, you’ll need to track the size of the array. Perhaps you could add a parameter to setVertices: representing the number of CGPoints that the array holds. Then other parts of the code that access _vertices could check that to make sure they’re not walking off the end of the array. And, like I mentioned before, make sure you free that memory before you reassign the pointer.

Messing about with pointers is fraught with danger. Tread carefully, there be dragons there.