On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo <dnovi...@google.com> wrote: > On 4/10/12 12:05 PM, Gabriel Dos Reis wrote: >> >> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<dje....@gmail.com> >> wrote: >> >>> 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. >> >> >> Fully agreed. > > > Indeed. My personal take on this is that it is going to be a gradual (for > some glacially slow) change. I think that debating these points in the > abstract gains us very little. > > Instead, each patch and/or API re-design should be discussed individually. > Patches will have specific metrics that can be collected. API changes will > be more of a bike shed, but it will at least lead to more concrete > discussions. > > The end goal for me is simple: modernize the code base to make it more > attractive to future developers. There is some balancing act to be done, in > that we should cater to the existing developers as well. But it is easier > for us, we already know the code and can influence the transition.
I think it's important to let the C folks slowly accomodate with C++, thus do not jump-start with even possibly questionable API changes. There are a _lot_ of "obvious" candidates that are even well contained (thus no fear of a can of partial-C++ transitions) like the various containers we use and APIs which are not in wide-spread use, like the cgraph API (which Honza is about to turn upside down). I also agree that exp->as_component_ref().get_field() is exceptionally bad. Both for the compile-time of the above expressions (three function calls that all are need to be inlined?!) and readability. And I've spent quite some time with various C++ codebases. None was as ugly as the above (and yes, I consider the LLVM C++ style exceptionally ugly as well). So, please no, do not even try to start the flamewar on C++-ifying trees or gimple. Not in the next three years at least. Propose a nice and usable C++ _plugin_ API that encapsulates trees and GIMPLE. _Then_ we can talk. Thanks, Richard. > > Diego.
