This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Switching to C++ by default in 4.8

On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther
<> wrote:
> On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo <> wrote:
>> On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
>>> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<>
>>> ?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,
> Richard.
>> Diego.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]