[Mesa-dev] [PATCH 2/2] glsl: Rewrote _mesa_glsl_process_extension to use table-driven logic.
Paul Berry
stereotype441 at gmail.com
Tue Jun 28 10:58:24 PDT 2011
On 28 June 2011 10:01, Eric Anholt <eric at anholt.net> wrote:
> If I stumbled on this code, I'd have no idea what was going on. A short
> version of this description near the code might help us poor C
> developers who stumble on it that have never seen this stuff before.
Will do.
>
>> >> + case vertex_shader: if (!this->avail_in_VS) return false; break;
>> >> + case geometry_shader: if (!this->avail_in_GS) return false; break;
>> >> + case fragment_shader: if (!this->avail_in_FS) return false; break;
>> >
>> > Delete the spurious breaks.
>>
>> Geez, what was I smoking?
>
> They don't look spurious in the code quoted here. But they do look like
> some more whitespace would help a lot.
Aha, you're right! What I was smoking was
code-that-is-correct-but-not-obviously-so. Had I not tried to format
it so compactly it would have been clear why the breaks are necessary:
case vertex_shader:
if (!this->avail_in_VS) {
return false;
}
break;
...etc.
Lesson learned: my code was so terse that I forgot why it was correct
when reading Ian's comments.
>
>>
>> >> + for (unsigned int i = 0; i < Elements(_mesa_glsl_supported_extensions);
>> >> + ++i) {
>> >
>> > Just 'unsigned'.
>>
>> Really? I'm surprised you care about this detail, esp. considering
>> that there are many instances of "unsigned int" already in Mesa. But
>> I'll acquiesce, especially since I'm trying to talk you into letting
>> me use a little-known C++ feature above :)
>
> I personally always preferred unsigned int to unsigned. :)
>
Me too, but I'll try not to fan any flames :)
More information about the mesa-dev
mailing list