[Mesa-dev] r600g: status of the r600-sb branch

[Vadim Girlin]

On 04/20/2013 07:05 PM, Henri Verbeet wrote:
> On 19 April 2013 18:01, Vadim Girlin <vadimgirlin at gmail.com> wrote:
>> The choice of C++ (unlike in my previous branch that used C) was mostly
>> driven by the fact that optimization algorithms usually deal with a lot of
>> different complex data structures, containers, etc, and C++ allows to
>> isolate implementation of all such things in separate and easily replaceable
>> classes and concentrate on the logic, making the code more clean and
>> readable.
>>
> I'm sure it would be good fun to have a discussion about the relative
> merits of C and C++, though I think I've seen enough actual C++ that
> you're not going to convince me it's the better language.

I never wanted to convince you that C++ is better language, I just 
wanted to explain why I decided to switch from C to C++ in this 
particular case.

> However, I
> don't think that should be the main consideration. It's probably more
> important to consider what current and potential new contributors
> prefer, and on Linux, particularly for the more low-level stuff, I
> suspect that pretty much means C.

Well, it may be considered as a low-level stuff because it's a part of 
the driver. On the other hand, I'd rather think of it as a part of the 
compiler, and compilers (especially optimization algorithms) don't 
really look like a low-level stuff to me. Depends on the definition of 
the low-level stuff though.

To name a few examples, we can look at the compilers/optimizing backends 
used by mesa/gallium: GLSL compiler (written in C++). LLVM (written in 
C++), backends for nvidia drivers (written in C++)...

Vadim

>
>> I haven't tried to keep it as a series of independent patches because during
>> the development most changes were pretty intrusive and introduced new
>> features, some parts were seriously reworked/rewritten more than one time,
>> requiring changes in other parts, especially when intermediate
>> representation of the code was changed. It was usually easier for me to
>> simply fix the new regressions in the new code than to revert any changes
>> and lose new features, so bisection wouldn't be very helpful anyway. That's
>> why I didn't even try to keep the history. Anyway most of the code in the
>> branch is new, so I don't think that the history of the patches that rewrite
>> the same code few times during a development would make it more readable
>> than simply reading the final code.
>>
> I think I'm just going to disagree there. (But of course that's all
> just my personal opinion, which probably doesn't carry a lot of weight
> at the moment.)
>