[PD] free C lesson

[Spencer Russell]

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 at 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 at 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 at 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 at 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 at lists.iem.at mailing list UNSUBSCRIBE and account-
>> > > management -> http://lists.puredata.info/listinfo/pd-list
>> > >
>> > >
>> > >
>> >
>> > > _______________________________________________
>> > > Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-
>> > > management -> http://lists.puredata.info/listinfo/pd-list
>> >
>> >
>> >
>> >
>>
>> > _______________________________________________
>> > Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-
>> > management -> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management
>> -> http://lists.puredata.info/listinfo/pd-list
>>
> _________________________________________________
> Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management
> -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150817/44a70b46/attachment-0001.html>