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