On Tue, Apr 10, 2012 at 8:26 AM, Michael Matz <m...@suse.de> wrote: > Hi, > > On Tue, 10 Apr 2012, Jakub Jelinek wrote: > >> > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> > >> > e.g. >> > exp->as_component_ref().get_field() .. >> > exp->as_mem_access().get_base() ... >> > exp->as_mem_acesss().get_address() --> produces the >> > address expression for memory access >> > exp->as_mem_access().get_alias_handle () >> > >> > gimple_inst->serialize (&fixup_list) --> a virtual >> > function overriden by actual instruction types that knows its byte >> > code format. >> >> That silently assumes we want to change basic GIMPLE/tree data structures >> to virtual classes, which is a significant change that has a significant >> cost as well. E.g. all such changed data structures grow by a virtual >> pointer field. Those data structures are heavily optimized for memory >> footprint. >> Not to mention it is very questionable if the above stuff is more readable >> than what we currently have. > > Actually it's not questionable. The above stuff is _horrible_.
There seem to be at least four parts to this discussion about benefits of C++: 1) Object-oriented and class-based design 2) Optimization benefit or challenge 3) Debugging 4) C++ syntax Hopefully all will benefit and they all support one another, but they are not inherently linked and dependent upon each other. Developers who are used to C++ will be comfortable with / familiar with the syntax above and developers who are used to GCC's current syntax will not like the change. The real challenge is that there are many more developers familiar with C++ syntax than with GCC internals syntax. If we could allow each group their own view, life would be much better. Also, it will be more convenient to make this change incrementally, but the GCC community probably will not see much benefit until the transition is complete. That also means developers asserting benefits need to be realistic and separate their end vision from what actually can be achieved in the short and medium term. - David