This is the mail archive of the gcc@gcc.gnu.org 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
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo <dnovillo@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.gcc@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.


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