wishlist: support for shorter pointers

[David Brown]

On 04/07/2023 16:20, Rafał Pietrak wrote:
> 
> 
> W dniu 3.07.2023 o 18:29, Rafał Pietrak pisze:
>> Hi David,
>>
> [--------------]
>>> 4. It is worth taking a step back, and thinking about how you would 
>>> like to use these pointers.  It is likely that you would be better 
>>> thinking in terms of an array, rather than pointers - after all, you 
>>> don't want to be using dynamically allocated memory here if you can 
>>> avoid it, and certainly not generic malloc().  If you can use an 
>>> array, then your index type can be as small as you like - maybe 
>>> uint8_t is enough.
>>
>> I did that trip ... some time ago. May be I discarded the idea 
>> prematurely, but I dropped it because I was afraid of cost of 
> 
> I remember now what was my main problem with indexes implementation: 
> inability to express/write chain "references" with them. Table/index 
> semantic of:
>      t[a][b][c][d].
> is a "multidimentional table" which is completely different from 
> "pointer semantic" of:
>      *t->a->b->c->d
> 
> It is quite legit to do a full circle around a circular list this way, 
> while table semantics doesn't allow that.
> 
> Indexes are off the table.
> 
> -R

If you have a circular buffer, it is vastly more efficient to have an 
array with no pointers or indices, and use head and tail indices to 
track the current position.  But I'm not sure if that is what you are 
looking for.  And you can use indices in fields for chaining, but the 
syntax will be different.  (For some microcontrollers, the 
multiplications involved in array index calculations can be an issue, 
but not for ARM devices.)