Re: Switching to C++ by default in 4.8

[Richard Guenther <richard dot guenther at gmail dot com>]

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 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.