> I think you forgot to include this file in this commit. Yes, sorry. > This is one that I was going to give some review comments on. I really > want to have this change in 7.9, but the patch is going to need some > changes. When we first discussed using C++ in the GLSL compiler in > Mesa, we got some feedback about C++ features not to use. The main ones > on the list are: > > - RTTI > - Operator overloading > - Multiple / virtual inheritance > - Templates
I would suggest to avoid banning any feature, and instead allow all of them (in C++03 + TR1, until we decide that C++0x is OK too) and decide in each instance whether it is being used appropriately or not. That said, I removed both templates and operator overloading from the pass. Note that templates are often essential to write generic code and build collection classes. Also, I think you should start using the STL: there are several parts of the compilers that could use a std::map or std::unordered_map and are doing linear scans instead, resulting in potential catastrophic slowdown in pathological cases (e.g. finding induction variables). exec_node and exec_list should also take template parameters for the next/prev pointers: this would make the code more type-safe. RTTI is probably a better replacement for the as_IR_TYPE() functions: they can be written as dynamic_cast<IR_TYPE*>(foo) instead, or &dynamic_cast<IR_TYPE&>(*foo) if you want an exception on failure. Operator overloading can be essential in the places where it is natural (e.g. defining a type that can hold all possible numeric types of a language). Overloading the call operator avoids needing to introduce an unnecessary function name. Multiple / virtual inheritance is indeed best to use rarely: I can't think of any use of it in the current compiler. Exceptions are another possible "contentious" feature. > Based on my memory of the code, it should be pretty easy to eliminate > the use of templates. Yes, it's trivial, since the current code always uses the same parameter, and I did it in the current committed code. I also removed operator overloading. The best long-term solution would however be to add an ir_switch node and put the "switch_generator" code in a lowering pass for it. Recent version of GLSL have a switch construct anyway. Note that the current switch_generator only handles sequential cases and would need to be extended to non-sequential ones. This is nontrivial if empty fallthroughs are allowed because binary search doesn't always work (e.g. case 1: case 3: a(); break; case 2: b(); break). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
