Pointer iteration Question

[Dkpaintball]

@cncnotes This is a helpful way to think about it. Thank you. Also, the array size is declared earlier in the code

@cedarlakeinstruments

@cedarlakeinstruments

Notice that we don't use the "*" here as that would change the meaning of the statement. The pointer is now pointing to the second location of mesg.

So, using the asterisk in the Serial.read() is telling it where to put the data, but when incrementing it, the asterisk isn't needed because we are only moving the pointer("cursor") location and not sending data to that location, correct? Thank you so so much again for your responses.

[cedarlakeinstruments]

@madmark2150

Or am I wildly off base?

You are correct, but as a matter of principle I try to avoid any constructs that rely on remembering order of operation. It's too easy to make a mistake. I'd rather dereference the pointer and then do the increment as two separate statements.

[sterretje]

@cedarlakeinstruments

but as a matter of principle I try to avoid any constructs that rely on remembering order of operation

Amen to that.

[madmark2150]

cool, cool. I'm slowly gaining insight. TYVM! I thought it would parse l to r ...

[gfvalvo]

@cedarlakeinstruments

but as a matter of principle I try to avoid any constructs that rely on remembering order of operation. It's too easy to make a mistake.

While I generally agree with this (or using parentheses to make the order explicit), there are certain constructs that are so ubiquitous that you may as well commit them to memory. The "deference + post-increment" operation (*ptr++) is one of them. You're highly likely to encounter it in most any code example you study … assuming it's written by somebody that know what they're doing.

[madmark2150]

Yeah, fetch and increment is REALLY useful.

What I really notice is the "mapping" of Cx functions overlay almost directly with the underlying CPU. ++ is INC, -- is DEC etc. If it was easy in ASM, it got early and simple opcodes. The PDP-11 data types got glued into the 8x86 model. Lots of more or less register indirect opcodes hiding just behind the C syntax.

[b707]

@cncnotes

char* messageSent [10] = {};

I would read it as: messageSent is an array of 10, and is a pointer of char type.
It contains the address of the first item of the array.

It seems to me that you are confused. This is not "array is a pointer", but "array of pointers".

so, the declaration

char* messageSent [10] = {};

means "10 element's array of pointers to char"
Perhaps the difference seems insignificant to you - but then it leads you to an error:

@cncnotes

*messageSent [2]

So, for example, if the first item (index 0) is stored at memory address 0xFF23, the value of interest will be found (by the compiler) at address 0xFF23+2.

Your calculations are incorrect because messageSent is not array of chars, but array of pointers to char. Pointer has size at least 2 bytes(depend on architecture). So the value of interest will be found at address 0xFF23+2* (sizeof (char*)), for example on arduino it will be 0xFF23+4

[cncnotes]

Yes, you are quite right Brain lock. Thanks for correcting.
And indeed the difference is quite significant.