I am still somewhat new to pointer arithmetic. For our RenderWeirdGradient, for example, we fill the buffer by basically using a pointer we move across the memory (if I understand correctly). Say we wanted to fill just part of the buffer, my first thought is something like this:
Thinking of the equivalent using pointer arithmetic did not come as quickly to me, but I ended up with something like this:
I think I heard somewhere that [ ] in C is just literally shorthand for pointer arithmetic, but I'm not sure if that's actually true?
I guess I'm wondering if it's worth stumbling through the pointer arithmetic with these kinds of loops for educational purposes if nothing else. Are there any performance / design considerations with this kind of thing?
Curious to hear any thoughts. Thanks ^-^
1 2 3 4 5 6 7 | for (int Y = StartY; Y < EndY; ++Y)
{
for(int X = StartX; X < EndX; ++X)
{
((uint32*)(Buffer->Memory))[(Y*Buffer->Width) + X] = Color;
}
}
|
Thinking of the equivalent using pointer arithmetic did not come as quickly to me, but I ended up with something like this:
1 2 3 4 5 6 7 8 9 10 11 | uint8 *Row = (uint8 *)Buffer->Memory;
Row += (StartY * Buffer->Pitch);
for (int Y = 0; Y < Height; ++Y)
{
uint32 *Pixel = ((uint32*)(Row)) + StartX;
for(int X = 0; X < Width; ++X)
{
*Pixel++ = Color;
}
Row += Buffer->Pitch;
}
|
I think I heard somewhere that [ ] in C is just literally shorthand for pointer arithmetic, but I'm not sure if that's actually true?
I guess I'm wondering if it's worth stumbling through the pointer arithmetic with these kinds of loops for educational purposes if nothing else. Are there any performance / design considerations with this kind of thing?
Curious to hear any thoughts. Thanks ^-^
Assuming that there is no operator overloading going on, then yes, []'s in C generally just does the pointer arithmetic that would have happened. You can think of
as being the same as
There's really not much to it.
In general, performance concerns come more from whether you do incremental or absolute offsets... ie., if instead you do:
and things like this, but these sorts of things usually depend on what the compiler was doing with your loops in the first place. Compilers are often smart enough to turn absolute-index loops into incremental loops when it is faster, etc.
- Casey
1 | Foo[X] = Y; |
as being the same as
1 | *(Foo + X) = Y; |
There's really not much to it.
In general, performance concerns come more from whether you do incremental or absolute offsets... ie., if instead you do:
1 | *Foo++ = Y; |
and things like this, but these sorts of things usually depend on what the compiler was doing with your loops in the first place. Compilers are often smart enough to turn absolute-index loops into incremental loops when it is faster, etc.
- Casey
Awesomesauce, thanks Casey, you're the man
@norswap: No, that is a perfectly well-defined and officially sanctioned operation in C as long as Foo and Y aren't aliased.
Ah indeed you are perfectly right. The increment can occur at any time during the evaluation of the assignment, but the pre-incrementation value is used. Since Foo does not appear somewhere else, there is no problem.
Something like `*Foo++ = Foo;` is actually undefined. I was bitten by something like that recently, hence a bit overeager to warn about the potential pitfall :)
Something like `*Foo++ = Foo;` is actually undefined. I was bitten by something like that recently, hence a bit overeager to warn about the potential pitfall :)