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...) Thanks,Jonathan
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
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
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
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
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
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
*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
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
I guess what I'm saying is that sc_vec is a loaf of bread, and the slices are t_word wide. So why are we doing the bookeeping (i.e., jumping to a particular location) in units smaller than one slice? -Jonathan
On Monday, August 17, 2015 1:54 PM, Forrest Curo <treegestalt@gmail.com> 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
Hi Spencer,The onset is in bytes, hence the cast to (char *). I'm just wondering why we're measuring things in bytes since an onset must always lie on a t_word boundary. Thanks,Jonathan
On Monday, August 17, 2015 2:29 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:
I guess what I'm saying is that sc_vec is a loaf of bread, and the slices are t_word wide. So why are we doing the bookeeping (i.e., jumping to a particular location) in units smaller than one slice? -Jonathan
On Monday, August 17, 2015 1:54 PM, Forrest Curo <treegestalt@gmail.com> 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
I can't remember why I thought that was the right thing to do... maybe I was trying to keep the possibility open to pack the data more efficiently (sticking two floats nto the size of one 'word'). But that seems like a lot of awkwardness for not much payoff. Maybe I had some other reason :)
M
On Mon, Aug 17, 2015 at 06:31:26PM +0000, Jonathan Wilkes via Pd-list wrote:
Hi Spencer,The onset is in bytes, hence the cast to (char *). I'm just wondering why we're measuring things in bytes since an onset must always lie on a t_word boundary. Thanks,Jonathan
On Monday, August 17, 2015 2:29 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:I guess what I'm saying is that sc_vec is a loaf of bread, and the slices are t_word wide. So why are we doing the bookeeping (i.e., jumping to a particular location) in units smaller than one slice? -Jonathan
On Monday, August 17, 2015 1:54 PM, Forrest Curo <treegestalt@gmail.com> 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
Thanks, Miller. Seems every time I have a question about C, even forming the question requires me to relearn pointer arithmetic. -Jonathan
On Monday, August 17, 2015 2:42 PM, Miller Puckette <msp@ucsd.edu> wrote:
I can't remember why I thought that was the right thing to do... maybe I was trying to keep the possibility open to pack the data more efficiently (sticking two floats nto the size of one 'word'). But that seems like a lot of awkwardness for not much payoff. Maybe I had some other reason :)
M
On Mon, Aug 17, 2015 at 06:31:26PM +0000, Jonathan Wilkes via Pd-list wrote:
Hi Spencer,The onset is in bytes, hence the cast to (char *). I'm just wondering why we're measuring things in bytes since an onset must always lie on a t_word boundary. Thanks,Jonathan
On Monday, August 17, 2015 2:29 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I guess what I'm saying is that sc_vec is a loaf of bread, and the slices are t_word wide. So why are we doing the bookeeping (i.e., jumping to a particular location) in units smaller than one slice? -Jonathan
On Monday, August 17, 2015 1:54 PM, Forrest Curo treegestalt@gmail.com 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
-
Claude Heiland-Allen -
Forrest Curo -
Jonathan Wilkes -
Miller Puckette -
Spencer Russell