On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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 think this is a good plan to move forward -- I also agree cgraph is a good candidate. Other candidates include optimization driver/pass manager, IR text dumper, persistent IR dumper/reader etc. > > 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?!) I find this less convincing -- the compile time cost should be very small -- and it may also allow more compile time saving: X* derived = p->asX(); // runtime assertion done once. derived->do_x_1 (); derived->do_x_2 (); .... As compared with a fat interface case: G* generic = p; DO_X_1 (generic); // runtime assertion needed DO_X_2 (generic); // runtime assertion needed ... > and readability. This is again very subjective -- and the style can be hidden under a macro. The benefit of using C++ API is not for the style change, but for proper interface partition. > 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). well, many people will probably disagree here. > > 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. I think keeping the core APIs in C is fine even though there are more work to make the current C APIs more user friendly. It might be a good idea to move the core APIs into a separate directory. thanks, David > > Thanks, > Richard. > >> >> Diego.
