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 <[email protected]>
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 <[email protected]>
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
<[email protected]> 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 <[email protected]> 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 <[email protected]>
>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
> ><[email protected]> 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
> >
> >
> > _______________________________________________
> > [email protected] mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
>
> > _______________________________________________
> > [email protected] mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________
> [email protected] mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
