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 <[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


_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to