macOS Struct pointer element signal

[Miglu]

I have this struct:

typedef struct node {
	CGPoint current;
	CGPoint next;
} node;

This is in the implementation:

	CGPoint location;
	location.x = [theEvent locationInWindow].x;
	location.y = [theEvent locationInWindow].y;
	struct node* noud;
	noud->current = location;

EXC_BAD_ACCESS occurs at the last line. What is the problem?

 

[lee1210]

You didn't allocate a node sized area of memory for noud to point to. You need to set it to point to a local node with & or get some memory with malloc.

-Lee

 

[Miglu]

Thanks. Is there a way to create a local node and set noud to point to it in one line?

 

[lee1210]

Thanks. Is there a way to create a local node and set noud to point to it in one line?

No, but there's a way to do it in two.

struct node myNode;
struct node *noud = &myNode;

I'm not going to try to compile this, but this might work?

struct node myNode, *noud = &myNode;

I would never do that, but it could work.

-Lee

 

[jiminaus]

Thanks. Is there a way to create a local node and set noud to point to it in one line?

If you going to create a local node that doesn't live beyond the current function, you don't need a pointer at all.

CGPoint location;
location.x = [theEvent locationInWindow].x;
location.y = [theEvent locationInWindow].y;
struct node noud;
noud.current = location;

This also has the advantage of not having to allocate memory for noud, and having to remember to free it at some point.

 

[SidBala]

Just wanted to address the point about using goto instead of loops.

Gotos(JMP) are actually used internally by the compiler to create loops anyway. So there is no reason you would want to eliminate a loop by using a goto. It is not any faster and lot less readable.

Of course that doesn't mean that there are no benefits to eliminating loops. But those usually involve removing the iteration itself and unrolling the whole loop.

 

[Sander]

By the way, from the name you gave your struct and its members, it seems you are trying to implement a linked list of CGPoints. Note that your "next" member should then not be of type CGPoint but of type pointer-to-node.

 

[Miglu]

You are right. I changed next to a node called nextNode.
I have a new problem with this same implementation. It is off topic, but I will save space on the forum by asking it here:

[nodes addObject: [NSData dataWithBytes:noud length:sizeof(noud)]];

const struct node* noud = [[nodes objectAtIndex: i] bytes];

Those lines are in different methods. The node's location CGPoint's x an y are not zero in the first line, and the nextNode is not 0x0. However, when I get the bytes back in the second line, y is 0 and nextNode is 0x0. What causes this?

 

[Miglu]

Instead of

typedef struct node {
        CGPoint current;
	struct node* nextNode;
} node;

if I do

typedef struct node {
	struct node* nextNode;
	CGPoint current;
} node;

nextNode is not nulled, but current is. Why is the latter data in this struct always destroyed by NSData?

 

[lee1210]

Instead of

typedef struct node {
        CGPoint current;
	struct node* nextNode;
} node;

if I do

typedef struct node {
	struct node* nextNode;
	CGPoint current;
} node;

nextNode is not nulled, but current is. Why is the latter data in this struct always destroyed by NSData?

sizeof(noud) is the size of a pointer. You need the sizeof(struct node) or sizeof(*noud).

-Lee