A pointer to a char (*char) is not the same size as a char. A pointer to a char is the size of a pointer on your machine (8 on a 64-bit machine).
But when you increment a char pointer it gets incremented by the size of a char (1) and when you increment a float pointer it gets incremented by the size of a float (4). Remember here that we're incrementing the *value* of the pointer, so we're incrementing the location of memory that the pointer points at.
This is so that if you have a bunch of data packed into an array, and you have a pointer to an element in that array, when you increment the pointer it is pointing at the next element in the array.
The reason that the (char*) cast happens is that the onset variable is defined to be measured in bytes, so if we want to increment the pointer by a number of bytes we have to make sure the compiler treats it as a char pointer. That doesn't seem to jive with your later email though, which says the onset is getting multiplied by sizeof(t_word). In that context it sounds like the onset is measured in words. Are you sure those are the same onset?
(sorry I haven't dug into the code itself, I'm going off of your emails).
-s
On Mon, Aug 17, 2015, at 01:54 PM, Forrest Curo wrote:
*char is guaranteed to be the same size as a 'char', 8 bits -- but if you're treating t_word as an array of char's, you can get into t_word and process it in 8 bit chunks.
On Mon, Aug 17, 2015 at 9:53 AM, Jonathan Wilkes via Pd-list <pd- list@lists.iem.at> wrote:
Ah, ok-- I forgot my pointer arithmetic rules. Once I remembered how it works, I still wasn't understanding how you could be doing pointer arithmetic with byte granularity when t_word is wider than 1 byte. But then I see from template_find_field you are multiplying the onset by sizeof(t_word).
So now, further down the rabbit hole of knowledge, I'm wondering why you multiply by sizeof(t_word) at all. If you didn't, couldn't the (char *) cast go away?
-Jonathan
On Monday, August 17, 2015 12:24 PM, Miller Puckette msp@ucsd.edu wrote:
I don't thing the width of (char *) enters into it (it's a pointer, 8 chars in 64 bit addr space) - the direct contrast to be made is (char) vs (t_word).
Not sure if that answers the question though...
cheers M
On Mon, Aug 17, 2015 at 03:52:27PM +0000, Jonathan Wilkes via Pd- list wrote:
Thanks, I think I'm getting it. So is char* guaranteed to be the same width as sizeof(t_word)? If so, are you just using it as a shorthand?
Thanks, Jonathan
On Monday, August 17, 2015 11:31 AM, Miller Puckette msp@ucsd.edu wrote:
Here's an example...
#include <stdio.h>
float foo[2];
main() { printf("foo = %p\n", foo); printf("incremented as float: %p\n", foo+1); printf("incremented as (char *): %p\n", ((char *)foo)+1); }
--->
foo = 0x601038 incremented as float: 0x60103c incremented as (char *): 0x601039
Adding an integer to a pointer "increments" it - the effect depends on the type of pointer. Another way to think of it is that foo[1], say, is semantically identical to *(foo+1).
cheers Miller
On Mon, Aug 17, 2015 at 03:10:35PM +0000, Jonathan Wilkes via Pd- list wrote:
But we're dealing with an array of t_words, so onset*sizeof(t_word) is what we want anyway, no? -Jonathan
On Monday, August 17, 2015 10:55 AM, Claude Heiland-Allen claude@mathr.co.uk wrote:
On 17/08/15 15:36, Jonathan Wilkes via Pd-list wrote:
Hi list,Wondering if someone will give me a free lesson in C programming. In g_traversal.c, there's some code to retrieve a float from a t_word* vec. It looks like this: *(t_float *)(((char *)vec) + onset)); Why does vec need to be cast to char*? t_word has to be as big as the largest member of the union, and the largest member has to be the same size as char*, right? (Otherwise we'd have big problems...)
aiui pointer arithmetic is in increments of sizeof(pointee) if onset is measured in bytes (I don't know if it is in this case, but it looks likely), then you need to have a pointer to bytes for the addition to be meaningful. vec is already a pointer, but adding onset to a t_word* would offset the address by onset*sizeof(t_word) bytes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account- management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account- management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account- management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list