Re: Switching to C++ by default in 4.8

[Xinliang David Li <davidxl@google.com>]

Mostly agreed. In particular, the discussions should be more concrete
-- instead of voting on moving everything to C++ which can create a
huge chaos, we should first carefully partition the components that
are candidates for the migration (as mentioned by Richard). For
instance,

1) core APIs
   a) tree based
   b) GIMPLE
   c) RTL

2) Call Graph component

3) Utility (vec, hash etc)

4) IR streamer and reader

5) IR text dumper

6) optimization driver and pass manager

7) Alias manager

8) Loop managers etc

9) Global Symbol table (do we even have one other than varpool ?)

10) Type table (non existing)

11) Local symbol table (almost non existing)

12) Bitwise data flow framework

13) target model

14) ...

and

*) CPP and parser (should I mention Clang? :) )

The direction for each component can be voted and the migration plan
and roadmaps can also be determined before hand.

For C++ifying any component, the owner/driver needs to come up with
detailed proposal first. There should also be some new style
guidelines. For instance, when migrating to STL container classes,
should they be used in 'raw' form, or some kind of GCC style wrapper
classes are defined, etc.

thanks,

David



On Wed, Apr 11, 2012 at 5:34 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
>> I have been having difficulty following the twists and the turns and
>> the goal post moving.
>> Are you essentially requiring to see GCC rewritten in C++ before we
>> switch to C++?
>
> Frankly, despite all this discussion, we still don't really know what
> the people who insist on a C++ conversion actually want to do. We've
> seen trivial suggestions like rewriting vec.[ch], which isn't really
> going to make a big difference in the grand scheme of things, but
> everything else has remained vague. At the GCC gathering last year we
> saw a presentation which made me feel like language features had just
> gone in search of possible applications, which doesn't fill me with a
> lot of confidence either.
>
> So yes, I would like some significant part rewritten in the way the C++
> folks would like to see it, so we can actually judge what we will get.
> And that's moving my personal goal post from "hell no" somewhere closer
> to what the C++ proponents would like.
>
> The incremental approach (tearing down the barrier of stage1 being
> compiled in C first and then getting things in piecewise) may seem like
> a path of less resistance, but we can't afford to have a thread like
> this for every change, and I wouldn't like to see us decide after 100
> patches that the end result sucks and we have to either live with it or
> revert the lot.
>
> IMO, gimple might be worth trying to convert, since it's the newest code
> in gcc and presumably already half-way to what people consider a
> "modern" style (lots of annoying little functions that get in the way
> while debugging).
>
> But I suspect that when such a branch has been done, it will still come
> down to personal preference as to which variant is best. This is why I
> still think the whole thing is deeply misguided, as it's not about
> objective technical issues, but merely about language preferences, and
> everyone has a different one. You can't match everyone's taste in a big
> project, and thus real developers have to adapt to a project, not the
> other way round. Discussions like this are a toxic distraction from real
> work.
>
> IMO it would be best if we could find a majority of global reviewers to
> speak out and say once and for all "no, this just isn't happening", so
> we can drop all this nonsense and get back to improving the compiler for
> users. The second best thing would be to have a branch with actual work
> done for us to consider.
>
>
> Bernd